Why HttpUnit?

Plenty of functional testing products for Web applications clutter the market. Most of them are aimed at Quality Assurance engineers looking for graphical automation tools. Given that HttpUnit is competing in the same space as all these fine beasts, why should an XP developer turn to HttpUnit?

One obvious answer is price. HttpUnit is an open source API that can be put into place without licensing fees or concerns about software piracy. Another advantage is HttpUnit's simplicity. The HttpUnit classes encapsulate in Java the basic mechanisms of maintaining client state, sending requests , retrieving responses, and following links. In addition, they provide handy shortcut methods to extract meaningful elements from an HTTP response (headers, tables, and so on). That's about all. HTTPUnit offers no proprietary GUI, automated test scheduling, graphical reports , or similar features.

Although these might seem like arguments against the software, they also mean that developers are free to provide their own customized solutions for these areas. For instance, HttpUnit tests could be combined with JUnitPerf's test decorators to provide a quick load-test. In addition, because HttpUnit tests are written in Java, they can be structured in almost any imaginable way. With other testing tools, test choices are limited to those anticipated by the team who wrote the tool. Finally, HttpUnit does not directly extend JUnit ”meaning that it can be put to use outside of a testing context (perhaps posting HTTP requests to a remote server from within a Java application).

HttpUnit provides fertile ground on which to build complex test suites; however, this flexibility comes at a price. A typical test case for a Web page that contained a form might be to fill out the form in several wrong ways, verifying that validation worked in each case, and then to fill it out correctly, checking that the appropriate subsequent page was displayed. Writing the Java code to perform this test could become cumbersome, because much of it would be repeated with minor changes (which form fields to fill out, which failure message was returned, and so on). Ideally, testing applications would be developed on top of HttpUnit to address some of these issues. One interesting technique (still in its early stages) is to create XML "scripts" for HttpUnit tests. The script defines which pages were consulted in what order and which assertions were performed on the results. New scripts could be written as new functionality arose, and the test suite would execute one test for each script. One such system has already been developed, based on JXUnit (http://jxunit. sourceforge .net/).

Because much of the value of functional testing comes in its thoroughness and scope (testing every user -visible feature of the whole application), and because the tests cannot be incrementally developed with the same ease as unit tests (many smaller components must be assembled before the test can be written), HttpUnit tests are not as lightweight or critical to XP as other types of tests. However, they can be deployed somewhat incrementally, and the features that HttpUnit provides to aid assertion writing (the ability to easily find hyperlinks in a response, for example) are unparalleled. It's worth considering HttpUnit as a developer if you have to write any assertions against a returned HTML page for any reason or if you need automated functional tests for your Web site and wish to leverage the flexibility of a framework instead of a tool.

HttpUnit vs. Cactus

HttpUnit and Cactus overlap each other's functionality. However, the basic difference is clear: HttpUnit performs functional tests, whereas Cactus performs unit/integration tests. See Chapter 18, "Cactus Primer," for a more complete delineation of the frameworks' respective roles, as well as for instructions on how use them together.