Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Wed, Apr 10, 2013 at 4:49 PM, Ihe Onwuka <ihe.onwuka@g...> wrote:
> On Wed, Apr 10, 2013 at 4:39 PM, Andrew Welch <andrew.j.welch@g...> 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] |
