Parasoft continues to send its Jtest Java testing suite out to hunt down bad Java code. And Jtest knows that the definition of bad Java code continues to expand: One bit of code might be bad because its developer didn't follow best practices for coding style, making it difficult for other programmers to understand and interface with it. Yet another bit might be bad because it is poorly factored and overly complex, or because it crashes when executed. A different bit of code might be bad because it was written with no consideration for security and could be easily compromised by a malicious hacker.
I've reviewed two previous editions of Jtest -- Jtest 7.0 and Jtest 5.0 -- but in Version 8, Jtest updates and extends several existing features. For example, Jtest 7.0's static-analysis engine came pre-loaded with 500 rules that allowed it to locate problems and coding violations by examining an application's source. The static-analysis component in Jtest 8 is equipped with more than 700 such rules.
New rules cover areas such as Java 5 specifics and Hibernate, and you can still define your own rules, although I found that process a bit complicated on account of the elaborate syntax Jtest employs. On the one hand, the language used to define rules allows you to cover a wide range of contingencies; on the other hand, the richness of the language creates a steep learning curve.
Jtest's static-analysis machinery has also been modified, turning it into a kind of static/dynamic hybrid. Specifically, the new BugDetective module examines source and class files (without executing them, mind you), explores execution paths, and uncovers potential bugs that would otherwise appear only after lengthy run-time testing.
BugDetective's execution explorations are not limited to a method, a class, or even a package; they can cross all logical boundaries. In addition, when it finds a problem, it not only locates where the problem is likely to manifest itself, but it also identifies the problem's origins so that you can tell where the "bad data" got into the system.
BugDetective will locate potential null-pointer exceptions, resource leaks (such as neglecting to close an opened socket), and a variety of security issues. In this last case, most of BugDetective's security rules locate code vulnerable to injection attacks: code that uses "uncleansed" user input to create a resource path string, or a query string.
Jtest 7's Test Case Sniffer technology returns in Jtest 8 under a new name, "Tracer." Tracer hooks into an application and gathers information about its execution. From that information, Tracer then creates a host of tests to launched against the application.
Most of the tests created are based on a JUnit foundation, but Jtest adds support for Cactus, a JUnit-extending framework from the Jakarta Project that recognizes just about every server-side component there is; HttpUnit, a general-purpose Web-testing framework that mimics a user executing from a browser; Springs; Struts; and other platforms.
Other improvements cover the entire Jtest tool collection. For example, past versions of Jtest generated tests at the class level. Now you can set filters on test creation so that tests are generated for, say, only public methods, ignoring private and protected methods.
Such "fine-tuning" of tests goes even further if Jtest is connected to a version control system. In that case, you can do things such as specify that Jtest create tests for only source code modified since a given date and restrict test generation to new code.
Bug Detective is perhaps Jtest 8's best addition. It can -- if you have the time -- be configured to exhaustively explore an application's execution paths. The default "exploration depth" is set to about 100 sequentially executed lines, but that can be adjusted to something much larger. And in this age of copious available processor cycles, it wouldn't be unthinkable to devote a small farm of test systems to simply sit around all night, exploring your Java source, and maybe finding something you wouldn't have expected. That's where Jtest shines brightest.