Cactus with Ant

If you've already read the sections on Ant and J2EE application assembly, then you probably have an idea of how you might use Ant to get test code onto the server for execution. Deploying test cases with Ant requires no new technical knowledge, but rather some strategic knowledge and some organization. The Cactus Web site (http://jakarta.apache.org/cactus/index.html) provides an in-depth tutorial on Ant integration and supplies custom tasks suited for Ant deployment (such as starting the server if it isn't already running). It's worth checking out these tutorials because this section will give you an overview of strategy rather than specific instructions.

The Strategy

To run Cactus tests, you must have several pieces in place, namely:

• The code under test must be deployed in the container.

• The test cases themselves (including the Cactus and JUnit JARs) must also be deployed on the server.

• If the server does not support hot deployment, the server must be restarted after a deployment.

• Before test execution, the server must be running.

• A test runner must call the Cactus test cases on the client side (thereby activating the server-side test code).

Ant is a natural choice for automating these tasks. In fact, if you accomplish all these steps, and the test suite exercises all the code, then you are practically in the presence of continuous integration! Of course, although the strategy appears simple, the execution is slightly more complex. In particular, the deployment of test code raises the question of how to deploy it in relation to the tested code.

A Web Application Just for Testing

The Ant integration tutorial on the Cactus Web site suggests creating a separate WAR file used only for testing purposes. The advantage to this approach is that it is self-contained. The testing WAR can be deployed easily alongside a production Web application, and builds and execution of test code will have their own space to run in. JARs used only by test cases (the Cactus and JUnit JARs spring to mind) don't pollute the class path of the working application. The chief drawback is having to pull all the code under test into the testing application.

Testing as Part of the Production Application

An alternate strategy is to build the testing into the application that it tests. This avoids duplication of code in two different WAR files. Also, test cases may be harder to separate from their code than to keep together. However, the production Web application will be laden with unexecuted test code. Of course, you could modify the Ant script so that a release build excluded the test code, but at the cost of added build script complexity.

The best solution is probably to experiment with different organization patterns and see which ones work and which don't. Unlike bare JUnit tests, Cactus tests demand at least deployment automation, and at that point it's worth going the extra mile to achieve continuous integration.