Experiments with JUnit, JSUnit and CppUnit

I spent a few hours over the last few days experimenting with recasting the NIST Java DOM test suite using Junit (http://www.junit.org) and then porting the Junit code the JSUnit (http://www.jsunit.net) and to CppUnit (if anyone wants to experiment with any of the other parallel frameworks at http://www.xprogramming.com/software like the C# one, I'd be interested in hearing your observations).  

I've been very encouraged and think that it looks like a very favorable mechanism for testing multiple language implementations without having to do extensive modifications to the tests.

A snapshot of my current experiment can be downloaded from http://home.houston.rr.com/curta/DOMUNIT.ZIP, but I plan to put it in the http://xmlconf.sourceforge.net CVS in the not distant future. 

I've basically gotten the attr and characterdata test classes to run under JUnit and JSUnit with only simple regex replacements needed to convert the JUnit test code to JSUnit.  The conversions for CppUnit are more complex but also seem to be doable with easily automatible changes.  

Using a diff utility that shows intraline changes will probably give you the best idea of the changes involved between the files, but I'll try to outline the major changes necessary.

The first step was to convert the original NIST Java tests to JUnit (with some specific patterns used to simplify the further ports to other platforms).

In JUnit, any public method starting with test and taking no parameters is considered a test method.  private or protected functions (such as getStaffDocument()) are used to support the tests.  Each test class (such as attr) extends DOM1TestCase which provides common utility routines and DOM1TestCase extends junit.framework.TestCase

Instead of building and returning a TestResults object, the test status will be based any calls to assert...() or fail...() methods (such as assertNull, assertEquals, assertNotEquals...) in the test code.

It is not necessary or desirable to catch unexpected Exceptions, so all unexpected exceptions fall through to the calling code that will give the case an error status (as opposed to a fail or success status).

Expected exceptions are handled with code that looks something like:

public void testSomeExceptionShouldBeRaised() {
    //  test set up
    try {
        //   do something
    }
    catch(DOMException ex) {
        if(expectedException(ex,SOME_DOM_CODE)) {
            return;
        }
    }
    fail(desc);
}

To ease porting to JavaScript, helper functions are used to access things that are properties in the ECMAScript binding.  For example, accessing the attribute name would be done as "attr.name" in JavaScript and "attr.getName()" in Java.  To move out of the test code, a "getName(node)" method is used in the test body which is implemented in the DOM1TestCase.java or DOM1TestCase.js file.

Cast operations are done using a "toCharacterData(node)" (for example) helper function as are the inspection of Exceptions.

The JUnit tests can be run (testing any JAXP complient parser) by something like:

java -classpath domjunit.jar;junit.jar;xerces.jar net.sourceforge.xmlconf.domjunit.DOM1TestCase

- or -

java -classpath domjunit.jar;junit.jar;jaxp.jar;crimson.jar net.sourceforge.xmlconf.domjunit.DOM1TestCase

which will run the attr, characterdata and cdatasection tests using staff.xml et al stored within the zip file.

The JSUnit tests can be run (testing MSXML3) by placing the tests in a directory that is a sibling to the jsunit/app directory, loading jsunit/testRunner.html in Internet Explorer 5 and then selecting the attr.html or characterdata.html file.  JSUnit claims Netscape support, but requires an explicit enumeration of the test methods which I haven't done for these tests.

The CppUnit tests compile for Xerces-C (current DOM), but the method bodies have not been written for the support routines.