[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XML and unit testing
- From: Nicolas LEHUEN <email@example.com>
- To: 'Leigh Dodds' <firstname.lastname@example.org>, 'xml-dev' <email@example.com>
- Date: Thu, 05 Jul 2001 11:58:04 +0200
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.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 ?
Responsable R&D - Head of R&D
Ubicco - Multi Access Software Solutions
>De : Leigh Dodds [mailto:firstname.lastname@example.org]
>Envoyé : jeudi 5 juillet 2001 10:57
>À : xml-dev
>Objet : RE: XML and unit testing
>> -----Original Message-----
>> From: Simon St.Laurent [mailto:email@example.com]
>> Sent: 04 July 2001 19:30
>> To: firstname.lastname@example.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
>> at the time of their creation but morphed by the time they
>> 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
>with it. Admittedly I haven't been pushing the tool as far as
>to, but it hits the 80/20 point for me.
>I usually follow the XP/Refactoring approach and build the
>the code. I've found that this not only has the benefits of
>code immediately, but also puts you firmly on the 'client' side of your
>API / interfaces. This has generally lead to improvements in
>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
>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,
>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
>> 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
>unit test has done what its supposed to: identify a failure.
>The xml-dev list is sponsored by XML.org, an initiative of OASIS
>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: email@example.com