You must understand that your Cactus tests are started by a JUnit
Test Runner (in the client JVM) and that the Cactus TestCase that you
have extended will connect to the Cactus Redirector (in the server
JVM), where your testXXX()
methods will be executed. See
How it works to understand the
mechanism.
Please also check the TestRunner Howto tutorial which explains all the different ways to start a JUnit Test Runner.
The Cactus tests are started by running a JUnit Test Runner (For explanations on how JUnit works see the JUnit web site). As pictured in figure 1, you need to have the following jars and classes in your client side classpath:
junit.jar
: obviously this is needed
for the JUnit Test Runner and because the Cactus
XXXTestCase
classes extend the JUnit
org.junit.framework.TestCase
class.
cactus.jar
: well, this is the
Cactus jar containing the core Cactus framework. Depending
on the J2EE version you are using it is named
cactus.core.framework.uberjar.javaEE.[J2EE_VERSION]-[CACTUS_VERSION].jar
XXXTestCase
classes,
servlet.jar or j2ee.jar
: these are
the Servlet API / J2EE API interfaces. This
is needed on the client side classpath because your test cases
extend one or several of XXXTestCase
which use class
variables that are Servlet / J2EE objects
(HttpSevletRequest
, PageContext
, ...).
You can get this jar either from your servlet engine or from the
Sun Web Site (
Servlet download page or
J2EE download
page).
httpclient.jar
: needed for
Cactus Cookie handling.
commons-logging.jar
: Cactus uses
the Jakarta Commons Logging facade framework to provide seamless
Cactus logging using any existing Logging framework (Log4j,
LogKit, JDK 1.4 Logging, etc). It is also needed for Commons
HttpClient.
logging framework jar
(optional): The
logging framework to use (Log4j jar, LogKit jar, etc). It is
optional as it is only needed for internal Cactus logging and in
addition, the Commons Logging framework provides a simple logger
that logs on the console.
httpunit.jar
,
Tidy.jar
and
xerces.jar
(optional): only needed if you
wish to use
HttpUnit
in your endXXX()
methods (see the
HttpUnit Howto tutorial).
The 3 jars mentioned above are part of the HttpUnit distribution.
aspectjrt.jar
:
AspectJ runtime jar.
testXXX()
method), you'll also need to put your classes
under test in the client side classpath.
cactus.properties
configuration file in your classpath (Only if you are using it to
configure Cactus of course). Details are described in the
Config Howto tutorial).
log4j.properties
Log4j configuration
file in your client side classpath (See the
Config Howto tutorial).
WEB-INF/lib/cactus.core.framework.uberjar.javaEE.[J2EE_VERSION]-[CACTUS_VERSION].jar
: the
Cactus core framework jar,
WEB-INF/lib/junit.jar
: this is
needed because the Cactus XXXTestCase
extends
the JUnit org.junit.framework.TestCase
class.
WEB-INF/lib/aspectjrt.jar
:
AspectJ runtime jar.
WEB-INF/lib/commons-logging.jar
:
Cactus uses the Jakarta Commons Logging facade framework to provide
seamless Cactus logging using any existing Logging framework (Log4j,
LogKit, JDK 1.4 Logging, etc). It is also needed for Commons
HttpClient.
WEB-INF/lib/logging framework jar
(optional): The logging framework to use (Log4j jar,
LogKit jar, etc). It is optional as it is only needed for internal
Cactus logging and in addition, the Commons Logging framework
provides a simple logger that logs on the console.
WEB-INF/classes/<your test classes>
: obviously as their testXXX()
methods will
get executed in the container.
WEB-INF/classes/<your classes under test>
: will be called by your test classes.
TOMCAT_HOME/common/lib
.
log4j.properties
Log4j configuration
file in your server side classpath (usually in
WEB-INF/classes
).