Creating tests for Java components
You can use the component test wizards to create several types of tests for your enterprise-level Java components, including tests of individual methods, scenario tests, and tests of abstract classes, interfaces, and superclasses, You can also use the wizards to create stubs of classes that interact with the component under test.
NOTE: The component testing tools are intended for testing enterprise-level Java components and not client-side user interface components, such as Swing and AWT.
Method-level testing exercises the different conditions defined in the method code in isolation from other methods, allowing you to test each individual method independently. The focus is generally to ensure that the method correctly processes all of its possible inputs.
Scenario-based testing consists of testing a particular sequence of method calls from one or several public classes. When you create a scenario-based test, a single test case is created based on the sequence of method calls selected in the wizard.
You can use an abstract test to test Java interfaces, abstract classes, and superclasses. When you create an abstract test, the result is a test scenario that can be reused with any implementing class.
Abstract tests cannot be run on their own and do not include a test suite. To run an abstract test, you must make the test concrete, that is, apply the abstract test to a public class that implements the interface, extends the abstract class, or inherits from the superclass. You can make an abstract test concrete at the time of test creation if there are implementing classes available or at any time after the abstract test has been created.
Creating stubs for Java components
Stubs are classes that provide replacement implementations for the actual classes that the code you are testing interacts with. Stubs can be generated for Java components, for Enterprise JavaBeans (EJBs), and for Web services.
Stubs are typically used for the following purposes:
To isolate the testing of the component under test (CUT) from other classes or components that the CUT interacts with.
To implement unavailable classes or components that the CUT needs to interact with.
To verify the interactions of the CUT with external components.
To verify the behavior of the CUT when one of its service providers generates exceptions or atypical values.
You can define a stub of a Java class and reuse that stub in multiple tests. Once you create the stub, you define its behavior in the stub data table or you enter code in the user code class that is associated with the stub.
To replace the stub with the real class at any time, simply remove the stub from the test suite.
Changing the scope of a test project
After you create a test project, you might need to redefine the test scope so you can update the collection of components that are candidates for testing. To update the list of components in the project, you must modify the test project's Test Scope properties.
Component test projects group the test artifacts that you create using automated component testing. A test project is linked to one or more development projects that contain the components you want to test. This collection of components serves to define the scope of the test. The scope of a test project can also use working sets that you have previously created in your workspace. Working sets are groups of elements for display in views or for operations on sets of elements.
Performance Testing with TPTP
The Eclipse test and performance tools platform (TPTP) supports automated performance testing of HTTP applications.
Recording a test
The test creation wizard starts when you start the test recorder. This wizard combines into a single flow these actions: the recording of a session with a Web application, the generation of a test from the recording, and the opening of the test in the test editor. You can record tests from Internet Explorer (the default on Windows) or from another browser.
Editing a test
You can inspect and modify a test prior to compiling and running it.
Generating an executable test
Follow this procedure to generate an executable test. Before a test can be run, the test's Java source code must be generated and compiled. This process is called code generation.
Running a test
You can run a test on one or more deployments.
Analyzing test results
At the conclusion of a test run you see an execution history, including a test verdict, and you can request two graphical reports showing a page response time and a page hit analysis:
The Page Response Time report is a bar graph showing the seconds required to process each page in the test and the average response time for all pages.
The Page Hit Rate report is a bar graph showing the hits per second to each page and the total hit rate for all pages. The exact numbers displayed at the top of the bars (availabe on the Page Response Time as well) do not appear unless you click one of the bars.
Data table elements
Expressions, sets, ranges, validation actions, initialization points, timing constraints, and objects are all elements that can appear in a row in a test data table. Each column pair of input values and expected outputs is considered one data set (equivalence class).
A timing constraint is a specialized validation action that you add to the test behavior code or to the test data table (TDT) to measure the duration of a method call or a sequence of method calls.
Timing constraints appear in the test behavior code as a pair of method calls, one to initialize the timer and the other to measure the duration. Each timing constraint appears as a row in the TDT, where you can define the timing constraint's values.
You can use one of several logical operators and units of time to define the value. Operators include <, >, =, <=, and >=. Units of time include nanoseconds, milliseconds, seconds, minutes, hours, and days.
For example, to verify that the total time of completion for a pair of messages is less than 3 seconds, you would define the value in the test data table row as < 3 seconds. To verify that the total time of completion for a pair of messages is greater than or equal to 2 milliseconds, you would define the value in the test data table row as > = 2 ms. If more than one message is being timed, the first message is considered the start message, while the last message is considered the end message.
Inserting timing constraints
You can define timing constraints directly in the test behavior code or from the test data table (TDT) to measure the duration of a method call or a sequence of method calls.
To add a timing constraint:
Open the test behavior source code in the Java editor. (To find the source code, open the Package Explorer view, expand the test project you are storing the test in, and expand the Behavior folder.)
Position the cursor at the location in the code where you want to start the timer.
Right-click and click Component Test > Insert New Timer.
Specify a name for the timer.
The starting point for the timer is added to the test behavior code. For example, if the timer is named timerleak, the following code is added:
Position the cursor at the location in the code where you want to end the timer.
Right-click and click Component Test > Insert Timer Validation.
The timer validation is added to the test behavior code, and a new row is added to the test data table at the point where the timer needs to be verified. For example, if the timer is named timerleak, the following code is added:
In the test data table, insert a timing constraint for the timer. For example, to verify that the total time of completion for the methods you are timing is greater than or equal to 2 milliseconds, define the value in the test data table row as > = 2 ms.