[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Testing XML don't use xUnit
- From: Andrew Welch <andrew.j.welch@gmail.com>
- To: ihe.onwuka@gmail.com
- Date: Wed, 10 Apr 2013 15:45:07 +0100
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, then you
would just write the xquery accordingly. What do you think the
Schematron you write gets turned into?
> 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
--
Andrew Welch
http://andrewjwelch.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]