[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Testing XML don't use xUnit

  • From: Ihe Onwuka <ihe.onwuka@gmail.com>
  • To: xml-dev@lists.xml.org
  • Date: Wed, 10 Apr 2013 16:51:38 +0100

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.