[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Testing XML don't use xUnit
>> As I said, if that is a requirement for the test to handle, > > When would it not be. Why would you purposely write a non-resilient test. When you have XSDs for the input and output XML, you can write full paths if you want. If you don't know the full paths, then don't write a full path. The problem is if you write //name to get all //product/name elements in a 'resilient' way, and then a business/name element appears in the xml, your resilient test is looking a bit weak now. >> What do you think the >> Schematron you write gets turned into? >> > > what matters is the schematron you write not what it gets turned into. > If the path to the target document changes alot of the time the > schematron you write doesn't have to. Nor does the XQuery in the test.... Fwiw, other than oXygen, all the Schematron implementations I know are XSLT behind the scenes. Maybe it's different now. This is why its funny to be told xpath bad, schematron good. Its all the same. >> ?? As I said, it uses XQuery - you can set whatever context you like. > > I don't know what role Xquery plays in xmlUnit or anything similar so > you'll either have to explain how it works or bear with me. Perhaps this is where the confusion is - I posted about the test framework I wrote/use to test transforms in addition to validation, then you started this thread. In my test framework I provide methods to run xquery against the input and result xml. So, if you wanted to ensure your paths were from some <context> node, you coud do a let/return or a for $x in //context return, or even just a pure xpath //context/some/child In short: if the test author needs a context, they can sort it out themselves. Maybe you come from QA background, where the complexity needs to be abstracted away from the test authors who aren't developer level? > The fact is tests like this > >> String someValue = runQueryOnInput("/some/path/to/val/string(.)"); >> >> String valueInResult = runQueryOnOutput("/result/path/to/val/string(.)"); >> >> assertEquals(someValue, valueInResult); > > are brittle and non-resilient to structural changes for the reasons I said. > > If there is an xquery capability within xmlUnit that obviates the need > to expose the xpaths in the manner in of the example then my > recommendation needs to be modified accordingly but if there is such a > capability I don't understand why test cases like the one quoted would > be written in the first place because they are very very brittle. Those are my method names, nothing to do with xmlUnit. They also aren't brittle at all - if you know the full path to an element then use it, especially in a test that will be run thousands of times. This 'framework' works so well because it integrates with the build easily, gives the test author all of xquery to use, and is fast, meaning tens of thousands of tests can be run quickly, keeping the test-fix cycle nice and short. -- Andrew Welch http://andrewjwelch.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|