Jtest 5.0 Eliminates Excuses

eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Its no small trick to make software source code analysis a pleasure, but the excellent design and open-ended flexibility of Parasofts Jtest 5.0 combine to eliminate a developers excuses for releasing anything but the most refined grade of Java.

At different stages of a project, a developer can mean different things by the simple word “test.” Jtest 5.0, which ships to customers this week for $3,495, accommodates those many meanings by defining (or letting a developer define) many different test configurations. One configuration might merely compare the code against predefined or custom-built lists of style rules; another might generate and perform actual tests, based on the analysis of such properties as the input and output statements in a Java class, to probe for potential run-time problems.

During tests, eWEEK Labs found Jtest 5.0 intuitive in terms of specifying tests to be performed and understanding the results, which the Jtest workbench environment displayed in the same tree-structured format—using informative icons—that it used to display the structure of the code that was under review. Users of such mainstream Java tools as Borland Software Corp.s JBuilder will find Jtest straightforward.

When our errors invited obvious repairs, such as adding a “falls through” comment to a case-statement clause that lacked an explicit “break” or “return,” Jtest offered us a Quick Fix pop-up menu that described the suggested repair—or offered several options—and executed our choice with a click of the mouse.

We have two cavils, however, on this otherwise well-conceived feature that is new to this release.

First, the source code editor did not force the error into view before offering the list of repairs, and we can readily imagine a developer mistakenly looking at one error while inadvertently fixing—or perhaps, merely compounding—another.

This quirk interacted, unfortunately, with a more serious oversight. Choosing one of the suggested Quick Fix options made the source code change and removed the corresponding error from the list of outstanding problems; choosing Undo from the edit menu reversed the change to the code but did not restore the error alert to the display in the other pane of the environment. We had to rerun tests to regenerate the error list. We hope that this will be quickly addressed in a future release.

Code-quality tools annoy developers when they demand that code protect itself against errors that can never occur. We appreciated the Quick Fix options that added “design by contract” preconditions to our code, indicating that a situation was intended never to arise, as well as alternative actions to handle such cases correctly.

In general, Jtest 5.0 demonstrated careful human-factors design. We particularly liked the color-coded bar running down the right-hand margin of the Jtest 5.0 source code window that quickly gave us a sense of the location, clustering and types of errors found in our code, with one-click hyperlinking to the lines corresponding to each error.

In this regard, Jtest 5.0 builds on the foundation of the Eclipse Platform, which the open-source Eclipse Project describes as “an open extensible IDE [integrated development environment] for anything.” The Eclipse effort also enjoys the support of other premier toolmakers, including IBM, Borland, IBMs Rational division, Telelogic AB, MKS Inc. and SlickEdit Inc. The excellent navigation aids in Jtest 5.0 demonstrate the running start that a tool can get from having access to a full- functioned workbench framework, rather than wasting time on the reinvention of wheels.

Discuss this in the eWEEK forum.