Managing a large code base with multiple developers can be more than a full time job, especially if you want to ensure that all of the developers on the team build unit tests, confirm regression testing, and do all the other less-than-beloved tasks. Parasoft promises to make this job significantly easier with the introduction of the latest version of its testing suite, Jtest 8.0.

In Jtest 8.0, Parasoft add a number of interesting and exciting features. I couldn't test them all — I'm inherently a solo developer — but some of the development tool's features caught my eye even though I don't usually work in a team environment. At the top of the list was the Jtest BugDetective. I also explored the tools for test case generation and parameterization.

While it is fun to poke at someone else's code, I decided that the best way to measure the software was to see what Jtest thought of my own skills. With that decision firmly in hand, I pointed Jtest at the code base for the software I wrote and sell, PDAbs; I'm certainly familiar with every line of code in that application. Because my code may not be representative of others' work, I also ran Jtest on an open source application downloaded from SourceForge.

The short answer? I am impressed. Not with my own coding skill, but with Jtest and what it found in my code.

Jtest runs either on a workstation or in a networked server environment. To get the full use out of all of the features, the company recommends you run on a server that's connected to your source repositories. However, I used Jtest only on a workstation and not in the automated server configuration.

My only issue with the installation was that it did not run in Mac OS X. This came as quite a shock since Jtest is a Java application, and it runs on just about everything else. I am not quite sure why they decided not to include an OS X installer with the test suite but this oversight really needs to be addressed. Java developers are moving over to OS X in droves; their tools should follow.

Once in Windows, Jtest installed smoothly and integrated itself with Eclipse without any issues. Jtest also includes some integration with IntelliJ's IDEA, but that integration is not as complete as Eclipse, so I did not test it in this review.

BugDetective

Parasoft Documentation: A new technology that automatically identifies difficult-to-find runtime bugs — such as NullPointerExceptions, resource leaks, SQL injections, and other security vulnerabilities — without requiring test case creation or execution.

The BugDetective promises to automatically find runtime bugs in execution paths that may cross multiple methods, classes, or packages; check compliance to configurable sets of rules (700 built-in, including 100 security rules); corrects violations of 250 rules; and create custom rules.

I spent quite a bit of time working with the BugDetective and my PDAbs application, and it came up with a slew of issues. Quite a few were trivial, lazy coder, types of issues, such as not closing SQL Statements but closing the connection.

Overall, BugDetective caught some 30 programming errors in PDAbs, and a couple of dozen lazy programmer issues. I was quite pleased with the results, and agreed with almost all its findings. I was also quite pleased that the BugDetective caught a couple of very subtle errors in the code that would have taken me hours if not days to find — assuming I found them at all.

Which isn't to say that it's perfect. While Jtest caught a number of potential NPEs, it tended to go overboard a bit. For example:

private String someMethod() {
    StringBuffer sb = new StringBuffer();
    //do something with the buffer
    return sb.toString(); //2
}

private void someOtherMethod() {
    String s = someMethod(); //1
    //do something with s
}

In this example, Jtest reported a potential NPE just after 1 in the code sample. I disagree here. Since I control both someMethod() and someOtherMethod(), this should not be flagged as a potential error. Adding a NPE check here would just introduce code bloat. If anything, depending on the non-implemented portion of someMethod(), the NPE flag should be at 2.

There were a few other odd quirks and if I tried hard enough I could confuse the Jtest BugDetective. However, if it got confused, I could simply clear the previous results and run BugDetective again.