Unit performs automated testing for standalone Java applications that either run on the command line or serve as components. If you develop large-scale or distributed applications, however, you are most likely going to work with Java Web applications. Because Web applications communicate via HTTP rather than Java method calls, JUnit is poorly equipped to test Web applications. HttpUnit comes to the rescue. This freely available tool provides Web testing functionality that complements JUnit.

You can work with HttpUnit in isolation, or you can mix HttpUnit with JUnit, which allows you to utilize JUnit's reporting and regression features. Although it shares a similar name to JUnit, the HttpUnit library is more general-purpose than your average testing framework. It contains code for simulating a browser, including partial JavaScript support. HttpUnit is essentially a programmable Web client. You could even use it to write a Web spider that performs crawling and screen scraping.

The HttpUnit client API enables you to write tests that simulate a user accessing a Web-based application via a browser. It has many of the functions you expect a browser to have: cookie management for sessions, parsing of HTML content, form submittal via the GET and POST methods, authentication, and other features. You can check for certain content on the page, link by link and form by form, allowing you to verify that the application returns the proper results.

Recorded Macros vs. Programmatic API
The two primary methods for performing automated tests on Web applications are: [1] via recorded macros that can be played back and [2] via a programmatic API that parses HTTP responses. Recorded macros require frequent revisions and tend to be brittle. A programmatic API requires picking apart the HTML files received from the Web server and building object trees filled with HTML elements and textual content. This more flexible approach minimizes test maintenance in the most common cases and enables the testing of complicated functions in Web applications that return highly variable or complex HTML response pages. This is the approach HttpUnit takes.

The downside of API-based automated testing versus recorded macros is that the API-driven approach takes a little longer to set up. The quick setup time that pointing and clicking offers is hard to beat. Nevertheless, applications tend to evolve significantly over time, so the time spent maintaining tests tends to outweigh time spent setting tests up. Furthermore, the recorded macro approach suffers from the serious limitation that you must have the application code written before you can build the test for it. If you adhere to the test-first methodology, as extreme programming recommends, you are out of luck because you must have a working application to interact with before you can record your macro for playback.

This article is the first in a two-part series that goes through the paces of building a Web application with HttpUnit as a part of the development process. It focuses on a rudimentary phone list application that lets the user create, edit, and delete contacts and get a list of contacts. For simplicity, it avoids building database persistence to focus on the development process rather than the setup and installation process. However, it goes into coding that allows database persistence to be easily added later.

Requirements: You should have at least a rudimentary knowledge of what the J2SE 1.4 SDK is and how to use Ant. You should also know how to set up a stock distribution of Tomcat. This article covers Struts as well, but you do not have to know anything about it other than being able to download the Struts distribution and unpacking it. (For more information on Struts, consult the Struts documentation at jakarta.apache.org/struts. Struts is a useful Web application framework that improves maintainability of application code and is worth knowing if you plan to write large applications.)

Set the Development Environment
To get started with HttpUnit, download the distribution from www.httpunit.org. The latest version as of the writing of this article is 1.5.4, released in August 2003. The HttpUnit distribution includes both the source files in a subdirectory called src and the object files in a JAR file underneath the lib directory.

As a simple, instructive exercise for you first-time HttpUnit users, type "ant run-example" in the main directory. This will execute an example unit test written for HttpUnit. The example code is in examples/Example.java underneath the root. Table 1 explains what the example does.

First, set up the development environment. In the sample code included with this article, you'll find files called phonelist.tgz and phonelist-example-files.tgz. Versions of each of the two files also are available for other compression tools with endings of "tbz2" and "zip". Select whichever one is appropriate based on your platform and compression tool: the ".tgz" file is packed with tar and gzip; the ".tbz2" file is packed with tar and bzip2; the ".zip" file is packed with zip. This article gives instructions only for the ".tgz" file because it is the most prevalent format on Unix. The phonelist.tgz archive contains the fully functional application. The phone-example-files.tgz archive contains the files you will use to follow along with the sample development session.

Download or copy the phonelist.tgz file to your home directory. Unpack the file with the following commands:

mkdir ~/projects
cd ~/projects
tar xzf ~/phonelist.tgz
cd phonelist

The "mkdir ~/projects" command results in an error if the projects directory already exists, which is fine. You should just make sure it exists. To try out the application, first make sure that Tomcat is running and that the values of tomcat.install.dir and struts.install.dir are correct for your environment. Then, type "ant deploy". That should build the application and deploy it to Tomcat, where you can then access it via http://hostname:8080/phonelist. You should replace hostname with the actual host name of the computer running Tomcat. The application should be self-explanatory. You may want to look through the build.xml file in ~/projects/phonelist, because you will shortly go through the process of creating a software application.