The simplest of these is static testing. Jtest compares your Java source code against a set of predefined coding rules, checking source code against a variety of rules from over 20 different categories. As a programmer I generally dislike this type of automated source-code checking because it rarely takes into account my personal coding style. However, static testing is an invaluable resource for project managers as it helps ensure that coding styles are consistent across developers and programs. It's much easier to support and maintain code that's been built in a consistent fashion across modules. In this era of "guerilla" software development, such consistency checking is doubly important. Jtest allows you to edit the static testing rules, making the entire process much more palatable. Figure 1 shows the Jtest rules list in the overlay window.

You can pick and choose from the list of prebuilt rules, and you can use the RuleWizard to add customized rules. The complete set is then stored as a file that can be shared among developers. Thus the project manager can configure a single set of rules that can be applied across an entire team of developers. I was able to use Jtest on some sample Java code (as shown in Figure 1) and it quickly pointed out some of the most common mistakes. (Jtest can't access JAR-based code, for example, and you have to provide Java source files for static analysis.)

The second layer of testing offered by Jtest, white-box testing, checks to ensure that a class is structurally sound. (It doesn't attempt to verify that a class behaves according to specification.) With Jtest you may need to create some "test classes" to thoroughly exercise certain types of code (such as EJBs, RMI, and application server integration).

Black-box testing checks that a class behaves according to specification (test cases the user generates). It checks that the class produces the correct output (outcomes) for a given input (or set of inputs). Jtest can derive inputs from your code by using Design by Contract (DbC) instrumentation, and you can also create explicit test classes that Jtest will use to exercise your code. (Jtest's static tests can help you to verify that the DbC assertions are contained within your Java code.)

ParaSoft provides extensive documentation on its Web site, including tutorials, FAQs, and user manuals. I was relatively impressed with the amount of information available there for developers, and I encourage you to take a look. When the time comes to run a trial of the software, you can download it from the site, though you'll need to request a license key for Jtest. The key is machine-specific, that is, you can't use the software on multiple machines without requesting multiple license keys.

I was able to get the software installed quickly and easily. Jtest uses a Java-based user interface, and it's relatively speedy. The UI maps errors and deficiencies back to your Java source code, but it doesn't automatically coordinate the outline controls in the display windows. (You can select an error condition in the results display and Jtest will open up the appropriate detailed results window, but it's up to you to click through the detailed results window to get to the specific line items.) Jtest automatically handles regression testing, so I was able to make iterative changes to my code and fix errors as I went along.

JDJ Product Snapshot

Summary
Jtest 4.0 offers a nice platform for building consistent, well-tested Java applications. The integration of static, white-box, and black-box testing makes Jtest an interesting product, but to harness the complete power of Jtest you'll need to invest in the Design by Contract programming methodology.