Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Tools of the trade, Part 2

Jtest statically and dynamically analyzes your Java code

By Jeff Friesen, JavaWorld.com, 12/06/02

  • Print
  • Feedback

Page 6 of 7

  1. Click the toolbar's New icon to start a new test session.
  2. Use the Browse button on the Class Testing UI's Class Name panel to locate and highlight SortElementNames.class. It does not matter if SortElementNames.java is in the same directory as SortElementNames.class or even if SortElementNames.java exists.
  3. Right-click the Start icon and select the Dynamic Analysis menu item.


Jtest dynamically analyzes SortElementNames.class. Once complete, the Errors Found panel's Uncaught Runtime Exceptions section displays the results, which appear in Figure 5.

Figure 5. The Class Testing UI's Errors Found panel reveals three instances of uncaught runtime exceptions. Click on thumbnail for full-size image.

SortElementNames has problems. When Jtest executes either SortElementNames.sort(new String[] {}, 2); or SortElementNames1.sort(new String[] {null}, 2);, an uncaught ArrayIndexOutOfBoundsException occurs. When Jtest executes SortElementNames.sort(new String[] {null, null}, 2);, an uncaught NullPointerException occurs.

Although SortElementNames works correctly, the white-box testing portion of dynamic analysis reveals a class whose static void sort(String [] items, int n) method is unsafe. That method is unsafe because it does not validate parameters items and n. Anyone unaware of sort(String [] items, int n)'s limitations might write code to call that method using incorrect parameters, and the program would most likely fail with an uncaught runtime exception. White-box testing reveals such construction problems to you before your program ships.

Black-box testing determines whether a class's public interface performs to specification. This testing does not involve implementation details. Instead, it checks that a class produces correct output for each input. Inputs are most often obtained by examining a specification that defines the code's purpose. In contrast, white-box testing obtains its inputs from an examination of code structure.

Jtest does not automatically perform black-box testing. You must do one of three things before black-box testing occurs:

  • Add appropriate Design by Contract (DBC) Javadoc tags to a Javadoc comment that precedes a method declaration. When you do this, Jtest automatically generates test cases to ensure DBC contract obligations are met.
  • Add user-defined method inputs or test classes, which are test cases too complex to be added as method inputs. Refer to the Jtest documentation to learn more about that option.
  • Validate the outcomes of automatically generated test cases. Again, I refer you to the Jtest documentation.


I'll demonstrate black-box testing with the DBC option. DBC is a structured way to write comments that define contracts for valid code. Each contract requires code that calls a method to meet a certain obligation defined by the called method. For example, a contract between a square root method and calling code states that the calling code must never pass a negative argument to the square root method.

The square root example illustrates a precondition contract: Calling code must pass appropriate argument values to a method. Jtest supports additional contract types, including postconditions and invariants. The following example focuses on preconditions only:

  • Print
  • Feedback

Resources