[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Testing XML don't use xUnit
On Wed, Apr 10, 2013 at 4:49 PM, Ihe Onwuka <ihe.onwuka@gmail.com> wrote: > On Wed, Apr 10, 2013 at 4:39 PM, Andrew Welch <andrew.j.welch@gmail.com> wrote: >>>> 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. >> > I have never said writing // anything. Maybe you are presuming thats what is meant by a resilient test. > >> >>>> 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. >> So if the xquery you are referring to is your own homebrew... then my advice stands as is. Again Uche's post identifies the correct nuance.
[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
|