SV: XML and unit testing (strayed a bit)

[Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>]

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