Re: [xml-dev] Testing XML don't use xUnit

[Andrew Welch <andrew.j.welch@gmail.com>]

>> 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