Jtest promotes good Java hygiene
Combination of debugging and testing tools keeps your Java code squeaky-clean
Parasoft’s Jtest is a combination static-code analysis tool and souped-up JUnit-style unit-testing environment for Java. Its primary raison d’etre is to eliminate bugs so you don’t have to chase them down with a debugger. Its secondary use is as a regression testing tool, and this mixture of testing capabilities makes a powerful alloy.
Jtest automates two broad categories of testing: static and dynamic. The former is more properly called static analysis and involves examining your code for errors in syntax, style, standard, and usage, and other characteristics. Static analysis is driven by Jtest’s library of rules, of which there are two general kinds: those that apply to specific Java constructs (such as Enterprise JavaBeans (EJB) or servlets) and those that apply to generic Java code (such as metrics or formatting). Jtest also allows you to create custom rules for enforcing coding guidelines specific to your company.
Jtest examines your code’s generated class file, and—from the information it gathers—performs global static analysis to catch “soft errors” and poor coding practices, such as class fields that are never accessed.
Jtest’s dynamic testing includes automatic generation of white-box and black-box test code. The product can generate white-box tests because it examines code directly. Jtest looks at your code, creates tests that might generate uncaught exceptions, and unleashes those tests, logging any exceptions and errors for later examination.
Black-box testing verifies that code functions according to specification. A black-box test knows nothing about the internals of the code, only that if you pass a method a specific set of inputs, the method should return a specific output.
Jtest’s black-box test-case generation is guided by DbC (Design by Contract), a well-defined syntax for comments that describe a method’s inputs and outputs and—to some degree—specify important expectations that the method and its caller can count on. For example, a DbC entry might define that a particular method take a reference to an array as input, and specify that the reference cannot be a null pointer. Jtest examines each method’s DbC information and constructs JUnit-style black-box test cases.
Test-case-generating capabilities are reasonably elaborate in Jtest. For example, if a method takes a complex object as an input parameter (provided that the class definition for the object is in the classpath), Jtest will create test cases that do their best to construct test objects for the particular method. Also, Jtest automatically generates stubs for external code or code that employs a resource unavailable at test time. If a method being tested relies on data read from a file, Jtest will create stub code that simulates the read operation so the test can be completed.
The version of Jtest I examined arrived integrated with the Eclipse development framework, but other versions plug into Borland’s JBuilder and Together ControlCenter, IBM’s VisualAge, IBM’s WSAD (WebSphere Studio Application Developer), and Sun ONE Studio.
When you run the Eclipse-integrated version of Jtest against your source code, the tool performs static and dynamic testing in a single swoop, automatically generating and executing test cases (and any required stubs). All errors are then collected in the log window.
If the error is a coding-standard violation, you can double-click on its log entry and the source-code view is handily positioned at the offending line of code. Click on the light bulb icon in the margins, and a pair of dialogs open; one describes the violation, the other suggests a fix. Double-click on the suggested fix, and it’s made for you.
Runtime errors in the log window describe the violation, identify the line where the error occurred, and can be opened to reveal test case information and a stack trace. The test case information reveals the call that caused the problem, as well as input and output parameters.
Jtest does its job well, but does stand some competition. WSAD already has code for generating JUnit tests, and there’s freeware JUnit and several products for automating it. I wouldn’t be surprised to see tools like Jtest ultimately subsumed into IDEs; several companies are already working on this, including Borland’s move toward incorporating this sort of testing into JBuilder.
But until that type of integration happens, Jtest’s clarity and ease of use make it the sort of tool that should be in every programmer’s standard arsenal. Not only does it automate the creation and execution of JUnit-style unit tests, but its static and dynamic testing is roughly analogous to the grammar checking software found in word processors: it finds errors before they become big problems.
