RE: XML and unit testing (strayed a bit)

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

If I understood it well after reading from the URL you gave, the DOM Test
Suite Group is developing a language-independent unit-testing framework for
DOM2. But is this framework extensible for other technologies ? Say I
develop a XSLT processor, a XML filtering tool, or whatever software that
manipulates XML documents. What I need is a unit testing framework to make
sure that the result of some XML manipulation is as expected. Can I do this
with the DOM Test Suite ?

Regards,
Nicolas

>-----Message d'origine-----
>De : Dimitris Dimitriadis [mailto:dimitris.dimitriadis@improve.se]
>Envoyé : jeudi 5 juillet 2001 12:18
>À : Nicolas LEHUEN; 'Leigh Dodds'; 'xml-dev'
>Objet : SV: XML and unit testing (strayed a bit)
>
>
>It was this fact that made the DOM Test Suite Group to decide 
>in favour of
>developing a framework of our own, instead of tying ourselves 
>to frameworks
>for specific languages. 
>
>In order to allow for as many languages as possible to be developed, we
>express our tests for DOM in XML, and use XSLT transforms to 
>generate the
>specific language desired.
>
>This is still work in progress, but not for long, so please visit
>http://www.w3.org/DOM/Test for details on how to contribute, if you are
>interested.
>
>/Dimitris
>
>-----Ursprungligt meddelande-----
>Från: Nicolas LEHUEN [mailto:nicolas.lehuen@ubicco.com]
>Skickat: den 5 juli 2001 11:58
>Till: 'Leigh Dodds'; 'xml-dev'
>Ämne: RE: XML and unit testing
>
>
>JUnit seems to form a consensus as the unit testing framework 
>for Java code.
>But this does not address the specific needs of unit testing 
>of Java code
>manipulating XML data. A thing that would be great is a JUnit 
>extension like
>HTTPUnit for unit testing of web pages or Cactus for unit testing of
>servlets and JSP.
>
>A unit testing toolbox for XML could have those features 
>amongst many others
>:
>
>- XMLAssertUtils.areCanonicallyEqual(dom1,dom2), which would 
>compare two DOM
>instances for equality of their canonical form
>
>- XMLAssertUtils.areEqualRegardlessOfNodeOrdering(dom1,dom2), 
>which would
>compare two document in a data-oriented fashion 
>(<a><b>foo</b><c>bar</c></a>
>would be equal to <a><c>bar</c><b>foo</b></a>).
>
>- XMLAssertUtils.match(dom1,xpathExpressionAsString,nodeset) or
>AssertUtils.equals(dom1,xpathExpressionAsString,text) that would permit
>testing of individual nodes without writing complex DOM 
>manipulation code,
>or having to tackle with various XPath API
>
>- XMLAssertUtils.isValidForDTD(dom,dtd) that would ensure that 
>the document
>dom is valid for the given dtd. XMLAssertUtils.isValidForDTD(dom) would
>validate the document against its intrinsic DTD.
>
>- XMLAssertUtils.isValidForXMLSchema(dom,xmlSchemaDom) would 
>ensure that the
>document is valid for the given XML Schema
>
>- XMLAssertUtils.isValidForRELAXNGSchema(dom,relaxNGSchema),
>XMLAssertUtils.isValidForSchematronSchema(dom,schematronSchema)
>, etc. There
>could even be a generic Schema interface so that we wouldn't 
>have to make a
>difference between all schema languages
>
>- A kind of SAXAsserter that would compare two SAX event flow 
>for equality
>(two threads pushing SAX events on the same asserter)
>
>- Utility methods to handle input data for test cases as XML 
>data, without
>all the code overhead for setting up the parsing of a file 
>(the objective is
>to reduce the time needed to write fixtures)
>
>Is there such a toolset like this now, or is there someone 
>building one ?
>
>Regards,
>-----------------------------------------------------------
>Nicolas Lehuen
>Responsable R&D - Head of R&D
>Ubicco - Multi Access Software Solutions
>http://www.ubicco.com/
>
>>-----Message d'origine-----
>>De : Leigh Dodds [mailto:ldodds@ingenta.com]
>>Envoyé : jeudi 5 juillet 2001 10:57
>>À : xml-dev
>>Objet : RE: XML and unit testing
>>
>>
>>
>>> -----Original Message-----
>>> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
>>> Sent: 04 July 2001 19:30
>>> To: xml-dev@lists.xml.org
>>> Subject: XML and unit testing
>>>
>>
>>[...]
>>
>>> In testing a filter, I need to be able to test component 
>>pieces, some of
>>> which are plain old objects and some of which are representations of
>>> those objects as SAX events and/or XML.  I've had a number of cases
>>> involving shallow copying (finally fixed) where the objects 
>>looked great
>>> at the time of their creation but morphed by the time they 
>>reached the
>>> XML output, so I really need to be able to test these things in a
>>> variety of situations.
>>
>>I'm currently using Junit for testing all my code, and am 
>>pretty pleased
>>with it. Admittedly I haven't been pushing the tool as far as 
>>Lars seems
>>to, but it hits the 80/20 point for me.
>>
>>I usually follow the XP/Refactoring approach and build the 
>>tests in-step
>>with
>>the code. I've found that this not only has the benefits of 
>>testing your
>>code immediately, but also puts you firmly on the 'client' 
>side of your
>>API / interfaces. This has generally lead to improvements in 
>>those APIs.
>>
>>So my approach to your problem would be to build separate test cases
>>for the individual components first. If your filter delegates 
>>much of its
>>work to other objects, then these can be tested in isolation from the
>>filter.
>>
>>Admittedly testing the filter can be trickier particularly if you want
>>automated tests with a range of inputs. However I've found that adding
>>utility code to the test suites helps here.
>>
>>You might also want to consider Schematron for testing the output of
>>your application. The assertion mechanism can be used to check for
>>correct values and structure in the document.
>>
>>Mock objects are another possible avenue to explore. These are objects
>>that implement your application interface but don't actually do any
>>useful work (they may instead contain hard-coded test values, 
>>debug logging,
>>or
>>additional assertions). These can then be plugged into your 
>application
>>instead of the real implementation, allowing some additional 
>>kinds of tests.
>>
>>> So far, I've been using a set of test cases and my own 
>>eyeballs.  It's
>>> worked pretty well as far as figuring out high-level 
>>pass/fail, but does
>>> very little to help me track down where the pass/fail came from.
>>
>>I'd suggest that suitable logging might help here, as it seems 
>>that your
>>unit test has done what its supposed to: identify a failure.
>>
>>Cheers,
>>
>>L.
>>
>>
>>------------------------------------------------------------------
>>The xml-dev list is sponsored by XML.org, an initiative of OASIS
>><http://www.oasis-open.org>
>>
>>The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>>To unsubscribe from this elist send a message with the single word
>>"unsubscribe" in the body to: xml-dev-request@lists.xml.org
>>
>
>------------------------------------------------------------------
>The xml-dev list is sponsored by XML.org, an initiative of OASIS
><http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: xml-dev-request@lists.xml.org
>