Advertisement

Design by Writing Tests

Bill Venners: Unit testing is a way to write clients that can give you some insight into your API, but it seems rewriting XML processing examples from other APIs to XOM was more direct way to write clients.

Elliotte Rusty Harold: Unit tests are a way to make sure that methods do what you expect them to do. They don't really help you decide what methods you need in the first place.

Bill Venners: That's not what the test-driven development folks would say. They believe writing tests first in tiny iterations helps them discover a clean design. I know you like unit tests. Do you write tests first?

Elliotte Rusty Harold: My problem with writing tests at the very first stage is that the test suite doesn't show a compile error as a red bar. If your tests don't compile, you can't run them through JUnit. I think if the JUnit GUI were rewritten so it could load the test from source code rather than a compiled .class file, and then report a compilation failure as a problem, then writing tests first would become more plausible. I generally do write at least the signature and a simple method stub before I write the test. Sometimes, even when I've got the method doing nothing more than returning null, then I'll go write the test. But not before then.

So I still write the tests very early, but I don't like writing tests where the IDE immediately puts squiggly lines underneath the code to indicate that it doesn't compile. How annoying that is varies from one IDE to the next. It's not at all annoying in emacs. In Eclipse it's a little annoying. In IntelliJ IDEA, it's practically impossible to get anything done until your code at least compiles.

Next Week

Come back Monday, September 1 for the next installment of a conversation with C# creator Anders Hejlsberg. The final installment of this conversation with Elliotte Rusty Harold will appear September 8. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Talk Back!

Have an opinion about the design principles presented in this article? Discuss this article in the News & Ideas Forum topic, Designing by Dictatorship, Examples, and Tests.

Resources

Elliotte Rusty Harold is author of Processing XML with Java: A Guide to SAX, DOM, JDOM, JAXP, and TrAX, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020161622X/

XOM, Elliotte Rusty Harold's XML Object Model API:
http://www.cafeconleche.org/XOM/

Cafe au Lait: Elliotte Rusty Harold's site of Java News and Resources:
http://www.cafeaulait.org/

Cafe con Leche: Elliotte Rusty Harold's site of XML News and Resources:
http://www.cafeconleche.org/

JDOM:
http://www.jdom.org/

DOM4J:
http://www.dom4j.org/

SAX, the Simple API for XML Processing:
http://www.saxproject.org/

DOM, the W3C's Document Object Model API:
http://www.w3.org/DOM/

ElectricXML:
http://www.themindelectric.com/exml/

Sparta:
http://sparta-xml.sourceforge.net/

Common API for XML Pull Parsing:
http://www.xmlpull.org/

NekoPull:
http://www.apache.org/~andyc/neko/doc/pull/

Xerces Native Interface (XNI):
http://xml.apache.org/xerces2-j/xni.html

TrAX (Tranformation API for XML):
http://xml.apache.org/xalan-j/trax.html

Jaxen (a Java XPath engine):
http://jaxen.org/

RELAX NG:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=relax-ng