RE: XML and unit testing

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

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
>