Jtest continues its trek toward code-testing supremacy

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.

Click for larger view.

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.