Server-side Java testing with Cactus - JUnit in Action - page 279

At B we start by initializing the context in the setUp method (remember that this
method is called before each test method), and we get hold of a valid IAdministrator-
BeanLocal instance from the JNDI C . Then in each test method we invoke the methods
on the EJB with different parameters and assert the validity of the result D .
So far, we've covered what you need in order to write Cactus test cases. Before we
rush into the section that deals with execution of our Cactus tests, it's essential that
you get familiar with a project called Cargo. The tight integration between Cargo and
Cactus is one of the new features that facilitate running your tests.

14.6 What is Cargo?

What we've seen so far is pretty much the bulk of how to write Cactus tests cases. At
the beginning of the chapter, we mentioned that Cactus test cases are executed inside
the container. In this section and in the ones that follow we focus on how to integrate
execution of Cactus tests in your build lifecycle. In order to keep the Extreme Pro-
gramming principles, you need to execute the tests every time you make a build. This
requires a tight integration between Cactus and the build system—Ant or Maven. But
before we jump into that integration, you need to become familiar with a project they
both rely on: Cargo.
Cargo ( http://cargo.codehaus.org/) is an open source project started, again, by
Vincent Massol in 2004. The aim of the project is to automate container management
in a generic way so that we could use the same mechanism to start and deploy a WAR
file with Tomcat as we could with WebLogic or almost any other application server. It
provides an API around most of the existent Java EE containers for managing those
containers (starting, stopping, and deploying). But Cargo is a bit more than just an
API , and that's where its strength comes from; it provides Ant tasks and Maven (1.x
and 2.x) plug-ins for facilitating the management of those containers.
After this brief introduction to the secrets of Cargo you're probably asking your-
self, what's the connection between Cargo and Cactus? The Cactus team realizes that
the idea behind the project is great, but it seems as though there's too much of a
burden regarding the process of executing the tests. Once written, the tests need to
be packaged in a WAR or EAR archive; then the application descriptors need to be
patched with the appropriate redirectors. After that, before the execution gets
started, the archive needs to be deployed in a container that's already started . You've
probably already noticed the three italicized words in the previous sentence. And
you've probably already guessed that the main idea of the Cactus development team
was to hide all the complexity regarding the management of the container by means
of Cargo.
This gives us full automation. If we use Cargo's Ant tasks (or Maven plug-ins)
to start the container, then deploy the WAR / EAR in it, and then stop the con-
tainer we have achieved the Extreme Programming principles of continuous integra-
tion . Our build is fully automated, isn't it? That's all true, but deploying the archive
with the tests by itself doesn't do anything magical—we still need to figure out a