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 5 of 7

Figure 4. Jtest's editor highlights the source code line in Lines.java that conforms to the highlighted line in the Errors Found panel. Click on thumbnail to view full-size image.

Figure 4 reveals 50 to be the number of milliseconds that a thread sleeps. Though I probably should have used a nonliteral constant in place of 50, I did not because Lines is a throw-away demo. From a production-program perspective, however, replace literal constants with their nonliteral equivalents. You'll save yourself and your customers grief.

Note
For all static analysis rules except Global Static Analysis rules, Jtest parses the Java source file(s). For Global Static Analysis rules, Jtest examines a project's classfiles, which implies you must use the Project Testing UI to learn about violations to Global Static Analysis rules. Furthermore, those classes' source files are not needed if you care only about Global Static Analysis rule violations.


Perform dynamic analysis

Dynamic analysis executes a program, provides its input data, and examines its output to determine whether the program executes correctly. Jtest performs dynamic analysis by automatically creating test cases and feeding those cases (and, where applicable, user-defined test cases) to a program as it runs. Jtest divides its dynamic analysis capabilities into white-box testing, black-box testing, and regression testing.

White-box testing determines whether a program's classes are structurally sound. The idea is to examine a class's code and determine if any input exists that would cause that class's code to crash. From Java's perspective, do any inputs cause the code to throw an uncaught runtime exception?

Jtest performs white-box testing as follows: After analyzing a class's code, Jtest automatically generates test cases, runs the class's code, and feeds those test cases to that code to generate an uncaught runtime exception. If the exception occurs, Jtest reports—on the Class Testing UI's Errors Found panel or the Project Testing UI's Results panel—that exception as an error and displays the method-call stack trace that led to the exception.

For example, SortElementNames sorts an array of element name strings into ascending order:

Listing 1: SortElementNames.java

// SortElementNames.java
class SortElementNames
{
   public static void main (String [] args)
   {
      String [] elements =
      {
         "Uranium",
         "Helium",
         "Argon",
         "Hydrogen",
         "Calcium",
         "Sulphur",
         "Gold",
         "Zinc",
         "Copper",
         "Iron",
         "Germanium"
      };
      sort (elements, elements.length);
      for (int i = 0; i < elements.length; i++)
           System.out.println (elements [i]);
   }
   static void sort (String [] items, int n)
   {
      for (int pass = 0; pass < n - 1; pass++)
           for (int i = 0; i < n - pass - 1; i++)
                if (items [i].compareTo (items [i + 1]) > 0)
                {
                    String temp = items [i];
                    items [i] = items [i + 1];
                    items [i + 1] = temp;
                }
   }
}


Compile SortElementNames.java and run the resulting classfile. The output proves that the program has done its job. But is this program's single SortElementNames class structurally sound? To find out, complete the following steps:

  • Print
  • Feedback

Resources