[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XML and unit testing (strayed a bit)
- From: Nicolas LEHUEN <email@example.com>
- To: 'xml-dev' <firstname.lastname@example.org>
- Date: Thu, 05 Jul 2001 13:31:36 +0200
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 ?
>De : Dimitris Dimitriadis [mailto:email@example.com]
>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
>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
>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
>Från: Nicolas LEHUEN [mailto:firstname.lastname@example.org]
>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
>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
>compare two document in a data-oriented fashion
>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
>or having to tackle with various XPath API
>- XMLAssertUtils.isValidForDTD(dom,dtd) that would ensure that
>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
>, 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
>(two threads pushing SAX events on the same asserter)
>- Utility methods to handle input data for test cases as XML
>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:email@example.com]
>>Envoyé : jeudi 5 juillet 2001 10:57
>>À : xml-dev
>>Objet : RE: XML and unit testing
>>> -----Original Message-----
>>> From: Simon St.Laurent [mailto:firstname.lastname@example.org]
>>> Sent: 04 July 2001 19:30
>>> To: email@example.com
>>> 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
>>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: firstname.lastname@example.org
>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