Testing Classes That Reference External Resources

Jtest's multiple stub options let you automatically and precisely test classes that reference external resources.

Stubs are basically replacements for references to external methods. For example, you could use stubs to specify that when the method "stream.readInt()" is invoked, Jtest should use the value 3 instead of actually invoking the readInt method.

Stubs are mainly used:

To isolate a class and test it independently of other classes, or
To test a class before the external classes it uses are available.

If you are using automatically-generated test cases to test classes that reference external resources, you can:

Have Jtest automatically generate stubs,
Enter your own stubs, or
Have Jtest call the actual external method.

Jtest does not automatically generate stubs for user-defined test cases. If you are using user-defined test cases to test classes that reference external resources, you can:

Enter your own stubs, or
Have Jtest call the actual external method.

When you perform regression testing on classes that reference external resources, Jtest will automatically use the stub types (if any) that were used during the previous test run(s).

Defining Which Classes are "External"

You can indicate which classes are external by defining the "Tested Set".

The Tested Set is the set of classes and methods included in the current test. Any class outside of the Tested Set is considered external. When a class or method in the Tested Set references a class or method that is inside that Tested Set, the actual class or method is accessed. When a class or method in the Tested Set references a class or method that is outside that Tested Set, stubs are called.

The class under test and its inner classes are always included in the Tested Set. When Jtest creates a new project, its default Tested Set is comprised of all of the classes in the package and subpackages of each class under test.

The Tested Set will also include additional classes that match the prefixes specified in the Tested Set list.

To open the dialog box that lets you specify what other classes are included in the Tested Set, open the appropriate parameters window, then:

Open Dynamic Analysis> Test Case Execution> Stubs.
Double-click the Tested Set Includes node.
To add a class name prefix, enter or browse to it, then click Add. To remove a class name prefix, select it, then click Delete. You can use a specific class name prefix as well as any of the following tokens:
- $PACKAGE: This token is replaced by the name of the package under test.
- $PARENT: This token is replaced by the parent parameter value.
- <unnamed>: This token refers to the unnamed package.
Click OK to close the Tested Set dialog box.

Using Your Own Stubs

When you configure Jtest to use your own stubs, you have complete control over what values or exceptions an external method returns to the class under test-- without having to have the actual external method completed and/or available. You can enter your own stubs for both automatically-generated and user-defined test cases.

If a stub is not defined for an external method or if no options in the appropriate test parameter's Dynamic Analysis> Test Case Execution> Stubs> Options for Automatic Test Cases/ Options for User Defined Test Cases options are enabled, Jtest will call the actual external method.

For more information about entering your own stubs, see Using Custom Stubs.

Automatically-Generated Stubs

When performing white-box testing on classes that reference external resources (such as external files, databases, Enterprise Java Beans (EJB) and CORBA), Jtest automatically generates stubs for the resources and executes the stubs to get input for the call to the external resources; like Jtest's other automatically-generated inputs, these inputs are designed to provide maximum coverage of the class. When designing these inputs, Jtest assumes that a call to an external resource can return any input compatible with its return type.

These inputs are created as white-box stubs, and these stubs are used for both white-box testing and regression testing. When these stubs are used for white-box testing, Jtest executes the stubs and reports errors if any uncaught runtime exceptions occur from the stubs' input. When these stubs are used for regression testing, Jtest executes the stubs and reports errors if class modifications cause previously tested input to produce output other than the known or previous value.

You can view the stubs that Jtest automatically generated and executed in the Automatic Test Cases> Method Name> Test Case> Test Case Input branch of the View Test Cases tree. Automatically-generated stubs will be marked with a small, empty box. Each stub branch displays the method invoked as well as the value or exceptions returned by the stub. Expand the stub's branch to see the stack trace where the invocation occurred.

If the stub's values resulted in an error, the above information will also be displayed in the Errors Found Panel (if you are testing a class) or the Results panel (if you are testing a project).

Currently, Jtest can generate inputs for the following external resources:

java.io
java.net
java.sql

In addition, Jtest offers preliminary support for CORBA and Enterprise Java Beans (see below for details).

Note: This support for classes that reference external resources is preliminary and we welcome any suggestions you have on improving it.

CORBA

When you perform white-box testing on classes that call CORBA objects, Jtest automatically generates and executes white-box stubs for the Object Request Broker and for other CORBA objects referenced by the class under test. For example, if a client or CORBA class references another CORBA object, Jtest will assume that method calls to the other CORBA object can return any value compatible with its return type, generate and execute white-box stubs that contain appropriate input, and report any uncaught runtime exceptions that result from this input.

When you test a set of classes using the Project UI, Jtest skips automatically generated classes such as helper classes, client stub classes, server skeletons, etc..

Enterprise Java Beans

When you perform white-box testing on EJB classes, Jtest assumes that the beans referenced by the bean under test can return any value that is compatible with the return type for that method. This tests that the EJB bean class will behave correctly regardless of the other bean or beans' behavior or return values.

Before you test any business method in the EJB class, Jtest will invoke the bean initialization routines and provide a dummy container context. Previous Jtest versions called the class's constructor and invoked the business methods. If you prefer to have Jtest test business methods using this older technique, set the following environment value:

For Windows: set JTEST_OPT_SKIP_CREATE=ON

For UNIX: setenv JTEST_OPT_SKIP_CREATE ON