Introducing HttpUnit

HttpUnit is an open source testing tool for undertaking the functional testing of Web applications. Unlike its namesake JUnit, HttpUnit is not a testing framework but a Java API. The HttpUnit API provides a means of programmatically interacting with a Web application and enables the automation of sophisticated test scenarios.

The JUnit framework is covered in Chapter 14.

The HttpUnit API centers around four core classes, described in Table 15-2.

Table 15-2. Main HttpUnit Classes

Class	Description
WebConversation	Acts as the Web browser during the test and maintains all conversation state associated with the running test case and the Web application under test.
WebResponse	Represents the HTTP response received from the Web application and provides methods for conveniently inspecting the contents of the response.
WebForm	Used to represent an HTML form and enables a request to the server to be built up by specifying values to be submitted for the form.
WebRequest	Represents an HTTP request submitted to the Web application.

Using this API, all facets of an interaction with a Web application are controllable. The API provides an elegant mechanism for constructing and submitting Web requests and analyzing the response. This functionality alone makes it a useful utility for Web application development, not just for testing purposes.

Although HttpUnit is suitable for building unit tests, its ability to engage in a dialog with a Web application places it in the category of a functional testing tool. HttpUnit test cases are written from the perspective of the end user, and key business scenarios can be orchestrated and tested, making the tool ideally suited for constructing acceptance tests.

As a testing tool, HttpUnit is very simple. Its main strength is a clean and easily understandable API. Unlike many of the commercial Web functional testing tools, the feature set of HttpUnit is distinctly limited in comparison. HttpUnit offers no reporting capabilities or graphical analysis features for deciphering the results of test runs. However, all of these bells and whistles carry a price tag. Consequently, the open source nature of the HttpUnit distribution, combined with its effectiveness as a functional testing tool, has made it a highly popular choice for testing Web applications.

The latest version of HttpUnit can be downloaded from http://sourceforge.net/projects/httpunit/.

HttpUnit and JUnit

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.

Writing a Test with HttpUnit

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:

1. Access the physician application via the login page.

2. Confirm reaching the correct login page.

3. Obtain the physician login form.

4. Submit the login form with a valid username and password.

5. Confirm reaching the physician search page.

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.

Listing 15-1. Physician Login Test Case

 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", "[e-mail]");     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.

Chapter 14 provides information on how to run a JUnit test.

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", "[e-mail]"); 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.