Java News from Monday, December 1, 2003

Cortex has released Clover 1.2.4, a $250 payware unit test coverage tool. Clover modifies the source code to enable it to follow which statements are executed when, and keeps a running count of how many timems each statement is executed during the test suite. Any statement that executes zero times is not being tested. Unlike Jester (which I initially confused it with) Clover only tests whether the tests execute each statement. It does not test whether the tests correctly detect bugs deliberately introduced into the code. Ideally you'd want to use both a tool like Jester and a tool like Colver since they do different things. Clover integrates with Ant, NetBeans, Eclipse, and IntelliJ IDEA. It can generate test coverage reports in XML, HTML, PDF, or via a Swing Viewer. Java 1.2 or later is required.

Along with the announcement, Brendan Humphreys sent me a set of Clover reports for XOM. The results are interesting and target a few areas where I still have work to do. On the other hand, I think the overall numbers are a little too low. The tests appear to have run on every method in the API, rather than just the public and protected parts. He even tested the tests package itself. To my way of thinking, as long as all public methods behave appropriately under all possible inputs, the library is working. But now that I think about it, I'm not quite so sure that this really makes sense. In at least some cases if you can change something without breaking anything, then maybe the thing is too complicated? Maybe there's a test there that needn't be there? I need to explore this in more detail.

Clearly a lot of thought has gone into this product. One of the neatest things I noticed about Clover has nothing to do with code coverage testing. Clover depends on several common open source tools including Velocity, Antlr, iText, and Ant. Some of these may well be installed on any system where Clover runs. To avoid version mismatches, a frequent problem for Java programs, the libraries have been obfuscated and/or repackaged and included in the clover jar. This isn't a code hiding technique--they're up front that they've done it--just a way to make sure that Clover gets the right version of the libraries it needs. In reverse, this would prevents Clover's jars from getting in the way of other uses of those libraries on the system, including in the system being tested. What a neat hack, and so much easier than the custom class loaders I've sen used to do this in the past. I'm going to think about whether this is applicable to any of my projects.