Cactus with Ant

If you've already read the sections on Ant and J2EE app 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 ( 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:

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 app 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 app, 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 app. The chief drawback is having to pull all the code under test into the testing app.

Testing as Part of the Production app

An alternate strategy is to build the testing into the app 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 app 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.