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

The last of these points tells us that Cactus tests live in the container JVM . This brings
us to the next issue: if Cactus tests live in the container JVM , how are they executed?
Also, how do we see the result from their execution?

14.2.3 How Cactus works

Before we rush into the details, you need to understand a bit more about how Cactus
works. The lifecycle of a Cactus test is shown in figure 14.1.
Let's look at the steps in using the TestSampleServletIntegration Cactus test
from listing 14.2. Say, now we have a sample servlet that we want to test and also a
test written for that particular servlet. What we need to do now is package the serv-
let and the test, along with the necessary Cactus libraries, and deploy the package in
the server. Once we start the server, we have the test and the servlet in both:
deployed in the container and in our workspace on the client side. You can submit
the client-side Cactus test to a JU nit test runner, and the runner starts the tests.

E XECUTING CLIENT - SIDE AND SERVER - SIDE STEPS
The lifecycle comprises steps that are executed on the client side and others that are
executed on the server side (inside the container JVM ). Client side refers to the JVM in
which you started the JU nit test runner.
On the client side, the Cactus logic is implemented in the YYY TestCase classes that
your tests extend (where YYY can be Servlet , Jsp , or Filter ). More specifically,
YYY TestCase overrides JU nit TestCase.runBare , which is the method called by the
JU nit test runner to execute one test. By overriding runBare , Cactus can implement its
own test logic, as described later.
On the server side, the Cactus logic is implemented in a proxy redirector (or redirector
for short).

Figure 14.1 Lifecycle of a Cactus test