HOME
PRODUCTS
  Insure
  WebKing
  Jtest
  Jcontract
  CodeWizard
  C++Test
SUPPORT
PAPERS
ABOUT
WHAT'S NEW
EVENTS

Parasoft Tools that Debug




Automate White Box Testing

by Luke Andrew Cassady-Dorion


Application testing, an unarguably vital step in the development process, should occur in two distinct forms, black box and white box. In a black box environment, an application's internal structure is treated as an unknown quantity, and its features are probed by the user who has zero knowledge of the decisions made by developers. White box testing attacks the source code from the perspective of the developer. Individual methods are invoked with parameters representing all phases of valid input. For example, consider this method:

public int divideThis(int a, int b) {return a/b;}

Because division will fail when the denominator equals zero, a proper white box testing case for the divideThis() method, would invoke the method passing in a non-zero and a zero value for the "b" parameter.

Jtest from Parasoft not only allows white box testing of classes, it fully automates the process through an intuitive UI and an impressive set of features. The application sequentially invokes methods exposed by classes, continuously checking for uncaught runtime exceptions.

Returning to the earlier division example, Jtest would flag the divideThis() method as a potential problem spot. Although pointing out the situation is a benefit to developers, Jtest ignores any potential precondition assumptions you make about various methods. For example, if all code that invokes the divideThis() method checks that the denominator is non-zero before invoking the method, there is no reason to perform the check inside the method itself.

Jtest has the ability to execute its checking algorithms against a single class, a collection of classes, an applet, or an application. The decision about when to utilize the tool is one that developers will have to make based on their workflow. In practice, I have found that when working in a group environment it is best to run such checks before checking source code back into a version-control system. Introducing bugs into a system can have far reaching effects if they propagate to other developer's machines.

The figure shows the main Jtest UI as it appears after finding some potential problems in a class file. The lower section of the screen shows each of the methods and information obtained from the stack trace. If the source code is available for the target class, clicking on any of the exceptions identifies the line of code where it occurred. Moving further up the screen, note the section titled "Coverage". Code coverage is an important metric indicating the percentage of your actual code that was executed by Jtest Through execution of methods with all forms of different parameters, Jtest will likely execute as much code as is possible; however, some code is impossible to reach. Consider this code:

if(true) {System.out.println("this will always occur");} else {System.out.println("you have a better chance of winning the lottery and getting hit by lightning at the same time");}

Because the conditional if(true)will always execute, the other code will not be reached; this situation would be reflected in the coverage section.

Moving further up the Jtest screen, the section titled "Advanced" allows the configuration of various runtime parameters, both those accepted by the Java VM and ones such as include and exclude file accepted by Jtest Above the "Advanced" section, is a set of configuration options that allows the user to specify which of the various types of methods are to be tested. Often you will only want to test public and protected methods because as your internal private methods might only generate data that does not raise exceptions.

Jtest is a tool I want to add to my arsenal. With ever-shrinking development schedules, any assistance is much needed, and the potential savings provided by Jtest is rather impressive.

Luke Cassady-Dorion, a Sun Certified Java 1.1 Programmer, is a lead developer with Healtheon Corporation. Luke has deployed many enterprise-wide solutions written entirely in Java. He is the author of numerous articles on distributed computing and Java and co-author of the recently published Distributed Objects Unleashed! Luke can be reached at luke@luke.org


This review appeared in the February 1999 edition of Java Pro.

Tools to debug c++ and java
(888) 305-0041 info@parasoft.com Copyright © 1996-2001 ParaSoft