Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Test for fun and profit, Part 3: The XML test framework

Test your Java code with an XML-based testing framework

  • Print
  • Feedback

Page 3 of 4

Now that the defect has been identified, it will be easy enough to go back into the code and fix it. After doing so, we should run the tests again in order to make sure that we didn't break anything else in the course of our repair work.

Look once more at the Java source code above. You'll see that we've mistakenly added the StringBuffer instance to the output vector instead of its string representation (an easy enough mistake to make -- and one that I've made before). The listing below identifies the offending lines and suggest replacements.

In line 58...
 replace: if (stringbuffer != null) vector.addElement(stringbuffer);
    with: if (stringbuffer != null) vector.addElement(stringbuffer.toString());
In line 65...
 replace: if (stringbuffer != null) vector.addElement(stringbuffer);
    with: if (stringbuffer != null) vector.addElement(stringbuffer.toString());


The framework

Now that you've seen the framework in action, I'd like to describe the framework itself.

First, the framework is XML-based. I selected XML because it seems destined to become the standard language for describing information. It is also very clean, and tools for creating it are beginning to appear.

Second, the framework doesn't require coding. The test-description language is declarative, not procedural. I believe that this reduces the complexity of the tests and lowers the level of programming skill required to create them.

We next turn our attention to the Document Type Definition (DTD). A DTD defines a format that valid XML must follow. It specifies the complete set of acceptable tags and their relationships, as well as a number of other details. The power of XML lies in the fact that there is not a single official XML DTD (as is the case with HTML). Instead, XML DTDs can be tailored to the problem at hand -- in our case, testing:

<?xml version="1.0" encoding="US-ASCII"?>
<!-- test.dtd -->
<!ELEMENT testsuite (preamble?,test+)> 
<!ATTLIST testsuite
          name CDATA #IMPLIED
          >
<!ELEMENT test (preamble?,action,result)>
<!ATTLIST test
          name CDATA #IMPLIED
          >
<!ELEMENT preamble (constructor|method|field|primitive|null|get|set)+>
<!ELEMENT action (constructor|method|field|primitive|null|get|set)>
<!ELEMENT result (equal)*>
<!ELEMENT equal ((constructor|method|field|primitive|null|get|set),
                 (constructor|method|field|primitive|null|get|set))
          >
<!ELEMENT constructor (constructor|method|field|primitive|null|get|set)*>
<!ATTLIST constructor
          class CDATA #REQUIRED
          >
<!ELEMENT method (constructor|method|field|primitive|null|get|set)*>
<!ATTLIST method
          id IDREF #REQUIRED
          name CDATA #REQUIRED
          >
<!ELEMENT field EMPTY>
<!ATTLIST field
          id IDREF #REQUIRED
          name CDATA #REQUIRED
          >
<!ELEMENT primitive (#PCDATA)>
<!ATTLIST primitive
          type (string|byte|short|int|long|float|double|boolean|char) #IMPLIED
          >
<!ELEMENT null EMPTY>
<!ELEMENT get EMPTY>
<!ATTLIST get
          id IDREF #REQUIRED
          >
<!ELEMENT set (constructor|method|field|primitive|null|get|set)>
<!ATTLIST set
          id ID #REQUIRED
          >


Below is a definition for each of the DTD tags.

  • Print
  • Feedback

Resources