Enterprise projects commonly require three distinct working environments: development, testing, and production.

Figure 15-1 illustrates the three environments.

Figure 15-1. Environment setup.

In the development environment, software engineers write, unit-test, and integrate all source code for the system. This environment is likely to comprise developer workstations with additional machines for performing integration builds and housing source-control repositories.

The testing environment is where all formal testing takes place against regular, versioned releases of the system from the development environment. For tests to be meaningful, the test environment must closely resemble the production environment.

Production is the target environment for the system, and the testing effort must validate the system is capable of meeting all functional and nonfunctional requirements when operating in this final environment. Testing is unlikely to be possible in production because live systems are involved, hence the need for the testing environment to closely mirror that of production.

Testing as part of an iterative development methodology such as Extreme Programming (XP) or the IBM Rational Unified Process (RUP) is an ongoing process conducted throughout the entire software development lifecycle.

An iterative development process has a running version of the system available from the early stages of the project. This allows the project team to continually submit the system to a barrage of functional and nonfunctional tests. This constant and ongoing testing effort is a key strategy in reducing risk by confirming the system under development is able to meet customer requirements and design goals.

Formal testing should commence toward the end of each iteration. The process starts by delivering a versioned release into the test environment

Each release is subjected to a full range of functional and nonfunctional tests, and any arising defects and issues are logged for the attention of the development team. The release and testing process continues until the system is of an acceptable standard. The final iterations of a project focus intensely on the testing effort and look to deliver the finished system into production.

It is common for systems with a high defect rate to spend a substantial amount of time bouncing between the developments and testing environments. A long and involved testing process causes lengthy delays in getting the application into production.

Supporting rapid application development requires meeting two objectives:

A test-driven approach to development results in higher quality software with fewer defects. This point has critical implications for rapid development, as the number of defects found during testing directly relates to the project’s duration. Put bluntly, the more defects discovered, the longer the system takes to deliver to the customer. Moreover, a problem detected during the formal testing process is more expensive to rectify than if discovered during development. Rigorous testing during development pays dividends by enabling the detection and correction of defects close to their point of origin.

Reducing the time taken to execute all of a system’s functional and nonfunctional test cases is achievable with test automation. This approach speeds up the testing process without comprising the quality of the test performed. The benefits of automated testing for rapid development make this the main topic for this chapter.

An enterprise-level distributed J2EE application presents some very unique challenges to the tester, and regardless of whether manual or automated tests are used, the testing of a distributed application is an involved and complex process.

First, an application built on the J2EE platform employs a variety of Java-based technologies for the development of system components, which are distributed over remotely distinct tiers. Thus, the tester immediately has a multimachine environment to contend with, plus the headaches a network brings in the form of firewalls and corporate security policies.

In addition to the distributed environment, by leveraging the full capabilities of the J2EE platform, the architecture of a J2EE enterprise application could potentially involve the use of asynchronous messaging between systems, long-running business transactions being fired between heterogeneous systems, and critical business functionality being exposed to other systems as part of a wider service-oriented architecture.

Besides the sophisticated architectures made possible by the J2EE platform, enterprise systems present their own special challenges to the tester, with system operational attributes such as security, performance, scalability, and robustness requiring intensive test coverage. The sensitivities revolving around security alone often demand the skills of specialized QA experts.

Collectively, these points make the task of testing an enterprise system as complex for the tester as the task of development is for the software engineer.

Fortunately, test automation tools are available to help address the challenges presented in thoroughly testing J2EE solutions. These tools aim to both simplify the testing process and improve the quality of the tests conducted.

Tools that support the testing process fall into the following general categories:

Various testing tools are available as open source, although few offer the same level of functionality as the high-end commercial products. Table 15-1 lists some of the open source testing tools available to the Java enterprise tester for undertaking test automation.

The next sections cover the use and application of two of these tools: HttpUnit and JMeter. We first look at HttpUnit, an API that provides support for functional testing.

As HttpUnit is not a framework but an API, a method is required for running the tests. Although HttpUnit is independent of the JUnit framework, it is perfectly acceptable to use HttpUnit in conjunction with JUnit. With this approach, a standard JUnit TestCase is produced, and HttpUnit calls are used within the test to submit requests and evaluate responses to and from the Web application. Based on the responses received, JUnit assertions confirm whether the interaction with the Web application is behaving in accordance with its requirements.

The advantage of piggybacking HttpUnit tests on the back of the JUnit framework means JUnit now serves as a common mechanism for running both unit and functional tests on the project. This allows all functional tests to be run against a system before its release into a formal testing environment. Ideally, the functional test suite should run as part of a continuous integration build process.

To illustrate the use of the HttpUnit API for constructing functional tests, you must have a Web application ready for testing. Rather than select a public Web site, the example operates against the Avitek Medical Records (MedRec) example that comes with the BEA WebLogic Server installation.

The MedRec application allows physicians, patients, and administrators to log in to the system and perform activities according to their role. Physicians, for example, can log in and perform a search for patients, and then view a patient’s details.

As every interaction with the application involves submitting a username and password via a login page for authentication, we build a test around this functionality. Specifically, we test the physician login process with the following scenario:

To write a test for this scenario using HttpUnit, it is not necessary to have access to the code for the MedRec application. Instead, the test case is constructed by examining the source for each page through the view source option available from the browser. Tests confirm the presence of expected elements for each page.

Listing 15-1 illustrates a test case for the physician login scenario.

import junit.framework.TestCase;

import com.meterware.httpunit.WebConversation;
import com.meterware.httpunit.WebForm;
import com.meterware.httpunit.WebRequest;
import com.meterware.httpunit.WebResponse;

/**
 * Login test for Physician MedRec application
 */
public class PhysicianLoginTest extends TestCase {

  private WebConversation conversation;

  /**
   * Establish an instance of WebConversation for
   * running the test
   */
  protected void setUp() throws Exception {
    super.setUp();

    conversation = new WebConversation();
  }

  /**
   * Ensure search page is reached on valid physician login
   */
  public void testPhysicianLogin() throws Exception {
    // Establish connection with Web page
    //
    WebResponse response = conversation
        .getResponse("http://localhost:7001/physician/login.do");

    // Check we have the right application
    //
    assertEquals("Avitek Medical Records", response.getTitle());

    // Get the form for the login
    //
    WebForm form = response.getFormWithName("userBean");

    // Build up a request from the form
    // Ensure we specify the action button for the submit
    //
    WebRequest loginRequest = form.getRequest("action");

    // Submit a valid username and password
    //
    loginRequest.setParameter("username", "[email protected]");
    loginRequest.setParameter("password", "weblogic");

    WebResponse loginResponse = conversation
        .getResponse(loginRequest);

    // Check we are successfully through to the search page
    //
    String destinationPath = loginResponse.getURL().getPath();
    assertTrue(destinationPath.endsWith("search.do"));
  }

} // PhysicianLoginTest

The MedRec application launches from the WebLogic Quick Start menu, which conveniently starts the WebLogic server and deploys the MedRec application. With the system up and running, initiate the test case as for a standard JUnit test from either Eclipse or using one of the JUnit test runner applications.

The test starts by establishing a conversation with the physician application. Normally, we do this from a Web browser, but as this is an automated test, the equivalent of an automated browser is required. The WebConversation class serves this purpose and acts as the browser component in all communications with the application. The login page is accessed via a single call to getResponse() on the instance of WebConversation, passing in the URL. A WebResponse object is the result of a successful call. Methods on the WebResponse class enable the inspection of the response from the physician application in order to confirm we have received the expected response.

From the example, we can see how a JUnit assertion verifies the page’s title to confirm we have accessed the MedRec application.

assertEquals("Avitek Medical Records", response.getTitle());

It is one thing to validate a response from a Web application, but a proper test requires submitting requests. For the test in the example, we must supply both the username and password for the physician.

Using the getFormWithName() method on the WebResponse object, we can produce an instance of WebForm that enables us to build up a request to the server. The login page has only a single form, but the test requests the form explicitly by name.

WebForm form = response.getFormWithName("userBean");

From the WebForm object, a WebResponse is constructed. Note that we must specify the name of the submit button used for the form, because the form contains two buttons: a submit and a cancel. The call to getRequest("action") on the WebForm instance provides a readymade WebRequest.

WebRequest loginRequest = form.getRequest("action");

Using the WebRequest object, you can specify the username and password, and submit the request to the MedRec physician application. The setParameter() method on the WebRequest object allows the contents of the form to be built up. Submit the request by invoking the getResponse() method on the WebConversation instance and passing the request in as a parameter.

loginRequest.setParameter("username", "[email protected]");
loginRequest.setParameter("password", "weblogic");
WebResponse loginResponse = conversation
        .getResponse(loginRequest);

A valid username and password should take us to the search screen. The final act of the test is to confirm the page we have sent to by interrogating the path of the URL associated with the latest response from the application.

assertTrue(destinationPath.endsWith("search.do"));

The example should serve as a useful template for building more complex test scenarios. HttpUnit is an effective tool for creating exhaustive, automated functional tests for Web applications. HttpUnit is not suitable for testing Swing- and AWT-based fat clients. In this situation, consider using JFCUnit, which is designed for this very purpose.

The next section moves on to testing nonfunctional requirements and examines methods for conducting load and stress tests.

A key failing on many projects is that performance testing is not carried out until near the end of the project. If performance problems are not detected until later iterations in the project, drastic changes to the system’s underlying architecture may be necessary. Last minute efforts to correct performance-related problems put the quality and stability of the finished application at great risk. Moreover, such late changes could result in unacceptable delays in the delivery of the system.

A good test strategy combined with a software architecture that considers performance upfront in the development process guards against this danger.

You should use early project iterations for building exploratory prototypes that seek to validate the ability of the software architecture to meet all nonfunctional requirements. Tests constructed against such prototypes validate the architecture. Furthermore, these same tests remain available throughout the development of the system to ensure compliance with performance objectives as the application evolves.

Testing of this nature requires a suitable test automation tool. You can develop your own load-testing tool by building a framework to execute your automated functional tests multiple times from independently executing threads. Fortunately, the Apache Software Foundation has already developed such a tool in the form of JMeter.

The functional tests created in the HttpUnit example verified the behavior of the application for a physician entering a username and password at the login page and navigating to the patient search page. To test the system under load, we use a functional test scenario that goes one step further and initiates a patient search after passing the login page. The objective of the test is to evaluate the patient search under load.

The steps for the performance test scenario are as follows:

Figure 15-2 shows the JMeter GUI with a test plan open for executing our load test. Over the next sections, we examine how this test plan is built up and the purpose of each of the plan’s elements.

Figure 15-2. JMeter with the MedRec test plan open.

The test plan is comprised of test elements that control the execution of the load test. Elements are added to the test plan as nodes to the tree in the left pane of the JMeter GUI.

The tree structure enables the hierarchical organization of plan elements. Here is a description of the main element types we use in the MedRec test plan:

You add new elements to the plan by right-clicking a node in the tree and selecting the Add menu item from the element’s context menu. The action presents a menu of all child elements available for selection. We begin by adding a thread group to the top-level test plan node.

A thread group represents a virtual user, or tester, and defines a set of functional test cases the JMeter virtual user executes as part of the test plan. The JMeter GUI displays configuration options for the thread group element in the right pane.

There are several options of interest for a thread group:

The example contains only a single thread group, but the test plan node supports the addition of many thread groups, each with its own configuration and test cases.

For the example, the number of threads is set at 100 with a ramp-up period of one second. The thread group is set to run continuously.

A JMeter test plan can have many thread groups, each running a different functional test scenario. As the example is concerned with a only single test scenario, our plan contains just the one thread group element.

Configuration elements modify requests sent to the server. They work closely with the sampler elements, which are responsible for sending requests. The MedRec test plan uses two types of this element: an HTTP request defaults and a cookie manager. We add both of these elements to the plan as immediate children of the thread group node.

Logic controllers let you determine when JMeter issues requests. They direct the execution order of test plan elements, and so orchestrate the flow of control for a test.

JMeter provides a range of different logic controllers. Table 15-3 lists those that are available.

For the example, the flow of control sees the test case log in to the application and perform 100 patient searches. To achieve this, we use two types of controller: a simple controller and a loop controller.

Up until now, the test plan doesn’t do much. To put the MedRec application under some strain, we need to start sending some actual requests. For this, we need a sampler element.

A sampler submits requests to the target server. JMeter supplies several types of sampler elements, making it possible to test systems other than Web applications. Table 15-4 describes each sampler provided as part of the JMeter installation.

Because MedRec is a Web application, we must generate HTTP requests, and JMeter provides the HTTP request sampler for this purpose.

Our test scenario calls for two HTTP request sampler elements, one for making the login request and another for initiating the patient search.

Making a Login Request

The first page accessed as part of the test is the physician login. Navigating past this page requires submitting a login request to establish our security credentials for the session. This process involves issuing the appropriate parameters as part of the request: a username and password.

The login process was covered in the HttpUnit example for the login page using an instance of WebForm in Listing 15-1. JMeter works very differently from HttpUnit, but rather than cover the login page twice, let’s leave the discussion on how to submit request parameters with JMeter until we reach the search page.

For now, Figure 15-3 shows the configuration of the sampler for the login page.

Figure 15-3. HTTP login request settings.

Notice that some of the options for the request are blank. These include the Server Name or IP, Port Number, and the Protocol. You can ignore these options because the HTTP request sampler inherits these settings from the HTTP request defaults element created earlier and added to the top-level of the thread group.

Add the sampler for the login requests as a child of the simple controller. To complete the test case, we need a final sampler for the search request.

Submitting a Search Request

The patient search requires an HTTP request element as a child of the loop controller. This element sends the parameters for the patient search. The search page uses an HTML form element for sending search requests, so the sampler needs to mimic the action of the form.

Here is an edited extract of the HTML source for the patient search page showing the form:

<form name="searchBean"
      method="POST"
      action="/physician/searchresults.do">
    <input type="text" name="lastName" value="">
    <input type="text" name="ssn" value="">
    <input type="submit" name="action" value="Search">
</form>

The searchBean form takes either the patient’s name or social security number. Our test case uses the name for searching. Figure 15-4 shows the configuration of the HTTP request element for the form.

Figure 15-4. HTTP search request settings.

The HTTP request sampler in Figure 15-4 simulates the sending of the searchBean form as if submitted from a browser. To match the form, you first need to switch the method from a GET, which is the default, to a POST. The HTTP request sampler provides a handy set of radio buttons for making this change.

Next, the path setting for the request must correspond to the value of the action attribute from the form. Set this to /physician/searchresults.do.

For the final task, add the form’s parameters to the HTTP request. We are searching on the patient’s last name, so you can ignore the social security number.

Two parameters are required to initiate a search. The first is the lastName parameter and specifies a string for matching against patient surnames. The second parameter is the value associated with the submit button, in this case the action parameter, which is assigned a value of Search. Don’t forget to add this value, or the MedRec application will not know how to handle the request correctly.

The search request completes the setup of the test plan for running the test. However, the test plan is still not complete: we need to tell JMeter how we wish to view the data gathered from running the test. This is accomplished using a listener element.

JMeter uses listener elements for analyzing data gathered from the test. A selection of listeners is available, each providing a different presentation format for the data gathered during the execution of the test. In addition to rendering the data gathered by JMeter, each listener type can log the information collected to file for interrogation after the test plan has completed using other analysis tools.

The listeners elements interpret data for their parent thread group. Add a listener to the thread group node by right-clicking on the node and selecting Add, then Listener, and then choosing from the listener elements available.

The example test plan uses these listeners:

Refer to the JMeter documentation for a full list of listeners.

With the listeners in place, the test plan is complete and ready to run.

Before running a test, it is highly advisable to save the test plan first. The JMeter engine can potentially spin up a large number of threads, and things can go wrong. Always save the plan before starting the test just in case.

Set the thread group so it loops forever, and start the test from the Run menu with the Start item. You can stop the test with the Stop item from the same menu. By clicking on the different listener elements, you can observe the status of the test while it is in progress.

The listeners display the data gathered for the test. These next sections examine the information presented in the aggregate report listener and the graph result listener. Although JMeter provides a number of other inbuilt listeners, these two are indicative of the type of information JMeter generates for a load test.

Aggregate Report Listener

The aggregate report displays the following summary information for the login and search requests.

• Number of requests

• Average response time

• Minimum response time

• Maximum response time

• Error percentage

• Throughput rate in terms of requests per second

Figure 15-5 shows the results from the aggregate report listener for the example test plan.

Figure 15-5. Aggregate Report Listener.

The report provides a concise and easy-to-read representation of the data in table format. In this case, the MedRec application has maintained a high throughput for the given load.

Because the aggregate report listener displays summary information, it is not possible to see how the Web application behaved during the running of the test. Viewing this information requires a graphical listener.

Graph Result Listener

For a graphical display of the test results, the graph result listener plots several types of performance information, including data samples, the average and median sample times, standard deviation, and throughput.

Showing all of this information in black and white is hard to read, so the graph result listener shown in Figure 15-6 plots only the data samples and the average response times during the test.

Figure 15-6. Graph Result Listener.

The graph has the duration of the test on the X-axis and the server response times for HTTP requests on the Y-axis. The black dots are the individual timings for each request. Ideally, the time taken for the application to handle a request should be uniform. A reasonably tight grouping of the dots represents a consistent response time for each request. The load on the server was quite light, and MedRec coped with the load—illustrated by the X-axis topping out at only 552ms.

The line through the dots is the average. Again, this should be fairly even. Apart from the step curve at the start where the test was ramping up, this is certainly the case.

The testing of object-oriented systems is a huge topic and appropriately, Robert Binder has written a huge book on the subject. For an in-depth discussion on all matters relating to the testing process, Testing Object-Oriented Systems: Models, Patterns, and Tools [Binder, 2000] is an extremely inclusive read and has the honor of being the thickest publication on my bookshelf.

To find out about other open source testing tools, visit http://www.opensourcetesting.org.