In-Container Testing Using Cactus, JUnit, StrutsTestCase, and Ant

This section is based on the strutsCACTUS.zip file that's included on the CD-ROM that accompanies this book. Later sections of this chapter use different archives.

It turns out that every one of the test cases run in the previous section on mock object testing works fine as a mock object test. This is actually good because mock object tests are easier and more convenient to run than in-container tests. Mock object tests are easier because for in-container testing you need a container available for testing, at a minimum. Plus, you must get the code deployed and loaded in the container in order to test it. Many times this involves deploying the application and restarting the container to get the new code running.

Even so, there are some things that simply can't be tested any other way. With Struts applications, these things are generally related to container-based authentication or Model components . For example, if you have a Model component that needs to connect to an EJB container ”or even just a database ”it might be difficult or impossible to test this using the mock object approach. You might really need the container to be present to accurately test the code.

Fortunately, the developers of Cactus and StrutsTestCase have come to your rescue again. As you'll see in this section, developing and running in-container tests for Struts is almost as easy as developing and running the mock object tests in the previous section.

Modifying the Test Cases for In-Container Testing Using Cactus

The easiest place to begin is to modify the two test case Java files for in-container testing using Cactus. Because the developers of StrutsTestCase wanted to make it easy to use test cases for either kinds of testing, the only change required is that your test case file must extend a different base class in your Java file.

The base class you used for the mock object testing was servletunit.struts.MockStrutsTestCase . For in-container testing, you use servletunit.struts.CactusStrutsTestCase .

So, as you can see from Listing 20.4, only three lines are changed: the package statement, the import line, and the class declaration itself.

Listing 20.4 TestHelloAction.java ”To Modify for In-Container Testing, Modify Only the package , the import , and the Class Declaration

 package ch20.hello.cactus; import servletunit.struts.CactusStrutsTestCase; public class TestHelloAction extends CactusStrutsTestCase {     public TestHelloAction(String testName) { super(testName); }     public void testSayHello() {        setRequestPathInfo("/HelloWorld");        actionPerform();        verifyForward("SayHello");     } } 

The easiest way to make these changes is to go to the directory ${src.home}/ch20/hello and copy the entire subdirectory (including both Java files) to a new subdirectory called cactus . Then go into the cactus subdirectory and make these same changes to both of the test cases there.

When this is complete, you need to make a few changes to your build environment for all these tests to run correctly.

Modifying Your System Configuration for In-Container Testing Using Cactus

The changes you must make to your system configuration include adding some .jar library files to the application, inserting the new test cases to your Ant script, adding some configuration files for Cactus to run, and modifying the web.xml of your Struts Web app to configure Cactus.

Adding the Required Libraries to Your Struts Application

Because you're running Cactus to connect to Tomcat and run your tests directly in the container, two additional JAR files are needed:

• cactus-1.4.1.jar ” If you're going to run Cactus tests, you should probably add the Cactus library. The version this example application was tested with is Cactus 1.4.1.

• commons-httpclient-2.0.jar ” This JAR file contains HTTP client utilities that allow the JUnit tests run by Ant to connect to Tomcat.

• aspectjrt-1.0.5.jar ” An additional library file required by Cactus.

The files must be copied to the directory identified by Ant as the ${lib.home} for the build process. This ensures that the build process puts them into the .war file for the Web app.

Inserting the New Test Cases into the Build Script

The easiest way to configure Ant to run the two new test cases you just created for in-container testing is to just add two additional lines to the existing <junit> task in the struts-test target of your build.xml file.

The two lines to add are

 <test name="ch20.hello.cactus.TestHelloAction" /> <test name="ch20.hello.cactus.TestHelloActionMultiple" /> 

In the sample application, these lines are inserted directly after the two existing test cases.

Should you remove the two previous test cases? Of course not! The value of your test cases grows over time ”remove only test cases that are no longer valid. This enables you to maintain your code on an ongoing basis and yet rerun every test case whenever you perform a build. This is the real value of integrating the testing process directly into the build process as this chapter demonstrates .

Adding the Required .properties Files to Your Application

The Cactus library file you just added requires these three property files:

• cactus.properties ” This file holds the information required by the Cactus client software to help it locate the container that your tests are deployed in. The properties as they are used for this sample application are

   cactus.contextURL = http://localhost:8080/strutsCACTUS cactus.servletRedirectorName = StrutsServletRedirector cactus.enableLogging=true 

  The first property identifies the host and Web app your tests are located in. The second property maps to an entry that you'll make in the web.xml file of the Web app in the next section. The third property enables logging.

• log4j.properties ” This file contains configuration for the Log4J logging utility as it runs on the server.

• log_client.properties ” This file contains configuration for the Log4J logging utility as it runs on the client (via the Ant <junit> task).

Copies of these files are provided. Simply copy them to the top of your source path in your build directory (that is, copy them to ${src.home} ) and the build.xml automatically picks them up and deploys them for you.

Modifying the web.xml File in Your Web App for Cactus

Cactus runs by adding a servlet to your Web app where it accepts requests. Based on those requests, it then runs tests against the classes and objects running in your application. To allow Cactus to accept requests from inside your Web app, you must add an entry to your web.xml file to configure how it will work.

Listing 20.5 is the updated web.xml for the strutsCACTUS Web app that contains your code and test case files. The lines that were added are in bold .

Listing 20.5 web.xml ”The Web App Deployment Descriptor Modified for Cactus

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app   PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"   "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> <web-app>  <!-- Cactus Servlet Redirector configuration -->   <servlet>   <servlet-name>StrutsServletRedirector</servlet-name>   <servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class>   </servlet>  <!-- Struts Action Servlet Configuration -->   <servlet>     <servlet-name>action</servlet-name>     <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>     <init-param>       <param-name>config</param-name>       <param-value>/WEB-INF/struts-config.xml</param-value>     </init-param>     <init-param>        <param-name>debug</param-name>        <param-value>3</param-value>     </init-param>     <init-param>       <param-name>detail</param-name>       <param-value>3</param-value>     </init-param>     <load-on-startup>2</load-on-startup>   </servlet>  <!-- Cactus Servlet Redirector URL mapping -->   <servlet-mapping>   <servlet-name>StrutsServletRedirector</servlet-name>   <url-pattern>/StrutsServletRedirector</url-pattern>   </servlet-mapping>  <!-- Struts Action Servlet Mapping -->   <servlet-mapping>     <servlet-name>action</servlet-name>     <url-pattern>*.do</url-pattern>   </servlet-mapping>   <!-- The Welcome File List -->   <welcome-file-list>     <welcome-file>hello.jsp</welcome-file>   </welcome-file-list>   <!-- Application Tag Library Descriptor -->   <taglib>     <taglib-uri>/WEB-INF/app.tld</taglib-uri>     <taglib-location>/WEB-INF/app.tld</taglib-location>   </taglib>   <!-- Struts Tag Library Descriptors -->   <taglib>     <taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>     <taglib-location>/WEB-INF/struts-bean.tld</taglib-location>   </taglib>   <taglib>     <taglib-uri>/WEB-INF/struts-html.tld</taglib-uri>     <taglib-location>/WEB-INF/struts-html.tld</taglib-location>   </taglib>   <taglib>     <taglib-uri>/WEB-INF/struts-logic.tld</taglib-uri>     <taglib-location>/WEB-INF/struts-logic.tld</taglib-location>   </taglib> </web-app> 

The two additions to Listing 20.5 are 1) Identify a URI where Cactus can be accessed ( /StrutsServletRedirector ) and 2) tell Tomcat which servlet class should be invoked whenever a request is received for this resource ( org.apache.cactus.server.ServletTestRedirector ). This Cactus servlet then receives the test requests, executes them, and returns the response to the Cactus client being run by the Ant <junit> task.

Note that the URI /StrutsServletRedirector is the same URI that was identified in the cactus.properties file in the previous step.

Running the In-Container Test Cases and Viewing the Results

Hold on ”you're almost done!

Now that everything is configured and in place, you just need to build the application and deploy it, restart Tomcat to get it running, and then run your tests.

Notice that how you run the tests is one of the key differences between mock object testing and in-container testing. With mock object testing, you could run the tests just after building the application. In-container testing requires you to build and deploy the test cases before you can actually run them.

As before, you deploy the application to Tomcat by issuing the following Ant command:

  ant deploy  

After this completes and you've deployed the application, you might need to restart Tomcat. (In fact, I've found that I occasionally need to stop Tomcat, delete the old webapp directory, and then restart Tomcat to get the deploy to work correctly ”if you have problems, try it.)

Now that your Web application is deployed and running in the container, you can run your tests. To do so, simply type (as before):

  ant test-all  

Output from the test-all target should now read

 struts-tests:     [junit] Running ch20.hello.mocktest.TestHelloAction     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.524 sec     [junit] Running ch20.hello.mocktest.TestHelloActionMultiple     [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.973 sec     [junit] Running ch20.hello.cactus.TestHelloAction     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.924 sec     [junit] Running ch20.hello.cactus.TestHelloActionMultiple     [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.931 sec test-all: BUILD SUCCESSFUL 

Congratulations! Your in-container tests using Cactus are now working. From here, it's a simple matter to build up more and more sophisticated tests over time. After you've built up a significant library of test cases, you'll find that they make a significant impact on the overall quality of the code you produce.