Use Component Test features

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.

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.

Stub

Stubs are typically used for the following purposes:

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.

Stub

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.

  1. 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.

  2. Editing a test

    You can inspect and modify a test prior to compiling and running it.

  3. 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.

  4. Running a test

    You can run a test on one or more deployments.

  5. 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).

Timing constraints

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:

  1. 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.)

  2. Position the cursor at the location in the code where you want to start the timer.

  3. Right-click and click Component Test > Insert New Timer.

    Insert new timer

  4. 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:

    ComponentTest.startTimer("timerleak");								
    								

  5. Position the cursor at the location in the code where you want to end the timer.

  6. 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:

    ComponentTest.checkTimer("timerleak");
    								

  7. 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.

    Timer

BOOT.BY - Tech Industry News         Free SCBCD 1.3 Study Guide     Free SCDJWS 1.4 Study Guide     SCDJWS 1.4 Quiz     Free IBM Certified Associate Developer Study Guide     Free SCJP 5.0 (Tiger) Study Guide     Free Mock Exam Engine     Free SCWCD 1.4 Study Guide     IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide     Free SCBCD 5.0 Study Guide