Apache Jakarta and Beyond: A Java Programmeramp;#039;s Introduction [Electronic resources]

6.1. An Introduction to Cactus

When testing a Web application with HTTPUnit the testing code sits entirely outside the server being tested. The only interaction between the code doing the testing and the code being tested is the HTTP request and response, as shown in Figure 6.1.

By contrast Cactus provides an "in-container strategy," meaning a portion of the code doing the testing resides within the application. This portion is a servlet called the

redirector, and it acts as the central point of all Cactus activity.

The fact that the redirector is a servlet has two immediate consequences. First, there is a simple and obvious way in which the redirector is placed within the application server; it is installed like any other servlet. This can be accomplished with the following entries in web.xml, the application's configuration file:^{Chapter 17.}

   
<servlet>
<servlet-name>
ServletRedirector
</servlet-name>
<servlet-class>
org.apache.cactus.server.ServletTestRedirector
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ServletRedirector</servlet-name>
<url-pattern>/ServletRedirector</url-pattern>
</servlet-mapping>

Note that the servlet mapping must place the redirector at the top level of the application, or it would not be possible to map the servlet to "/chapter06/ServletRedirector." The servlet to be tested, however, may reside anywhere.

The second implication of having the redirector be a servlet is that it provides a natural way for an external program to invoke a test. The external program can make a regular HTTP request to the appropriate URL/ServletRedirector, in this caseand on receiving such a request the redirector will run the tests. The broad outline of this process is illustrated in Figure 6.2, which will be refined shortly. Figure 6.2 gives a sense of how Cactus works, but the picture is not yet complete. So far nothing has been said about the client. Since JUnit provides such a useful and flexible framework, the Cactus client will be constructed on top of it. This means that Cactus test cases will look much like JUnit and HTTPUnit test cases; they will be individual Java classes with specially named methods that a test runner will dynamically discover and invoke.

There are a number of ways in which the client could know which server and which URL to contact in order to invoke the redirector. Cactus looks for this information in a file called cactus.properties, which must be placed somewhere in the CLASSPATH on the client side. The cactus.properties file for this example contains the following:

cactus.contextURL = http://localhost:8080/toolbook
cactus.servletRedirectorName = ServletRedirector

Moving right in Figure 6.2, the next point of clarification is the communication channel between the client and the redirector. When HTTPUnit wants to test a page, it sends a request containing the URL, query string, POST data, and other elements intended for the page to be tested. When Cactus wants to test a page, the URL will be the URL for the redirector, not for the page or servlet to be tested. There must, therefore, be a mechanism for the client to tell the redirector how to run the test. This is done through an auxiliary class called a

WebRequest.

The full process by which a Cactus test runs is listed here, and it will be illustrated shortly in the context of an actual test case.

Items 2 through 12 are repeated once for each test, so if a test class defines testTest2 and testTest3 methods, then there will be three requests to the server, three server instances constructed, setup() will be called three times, and so on. This process is illustrated in Figure 6.3.