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

[Ihe Onwuka <ihe.onwuka@gmail.com>]

On Wed, Apr 10, 2013 at 3:45 PM, Andrew Welch <andrew.j.welch@gmail.com> wrote:
> On 10 April 2013 15:28, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:
>> On Wed, Apr 10, 2013 at 2:48 PM, Andrew Welch <andrew.j.welch@gmail.com> wrote:
>>>> I'm not sure what you think you might be missing because your previous
>>>> response suggested you got it.
>>>>
>>>> As far as possible you want your tests to carry on working unchanged
>>>> if the structure of the XML changes. That will not happen if your test
>>>> cases expose Xpaths.
>>>
>>> Examples please.
>>>
>>> if I compare //title in the input, with //title in the output - how
>>> will that not handle changes in the structures of the XML ?
>>>
>>> I've happily used this technique on 2 large projects now (I'm pretty
>>> confident in how it works : )
>>>
>>
>> I'll take your example from the other thread.
>>
>> Below if as the result of changes to the structure in the XMLe any of
>> the elements "some" "path" or "to" change, disappear, become reodered,
>> or now require predicates to be included, changed or removed that test
>> will not work. Note the multitude of things that the test is
>> vulnerable to.
>
> 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.

> then you
> would just write the xquery accordingly.   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.

>> String someValue = runQueryOnInput("/some/path/to/val/string(.)");
>>
>> String valueInResult = runQueryOnOutput("/result/path/to/val/string(.)");
>>
>> assertEquals(someValue, valueInResult);
>>
>> Uche correctly identified that it's the ability in Schematron to set a
>> context that makes it resilient to this problem.
>
> ?? 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.

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.