'개발방법론/모델링/Testing'에 해당되는 글 2건
== client side ==
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 all Cactus classes,
your test classes: these are your test classes that extend the Cactus 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
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.
If you have the habit of using class variables for the classes to test (as opposed to declaring them within the testXXX() method), you'll also need to put your classes under test in the client side classpath.
If you are using Log4J as the logging framework, you will also need to put a log4j.properties Log4j configuration file in your client side classpath (See the Config Howto tutorial).
---------------------------------------------------------------------
== server side ==
WEB-INF/lib/cactus.jar: the Cactus main jar,
WEB-INF/lib/junit.jar: this is needed because the Cactus XXXTestCase extends the JUnit org.junit.framework.TestCase class.
WEB-INF/classes/ : obviously as their testXXX() methods will get executed in the container.
WEB-INF/classes/
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.
If you have several webapps that use cactus you can put all Cactus jars in a place loaded by your container System classloader (provided your container correctly sets the Context classloader). The location is container-dependent; for example for Tomcat 4.x, you can put the jars in TOMCAT_HOME/common/lib.
If you are using Log4J as the logging framework, you will also need to put a log4j.properties Log4j configuration file in your server side classpath (usually in WEB-INF/classes).
-------------------------------------------------------------------------
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 all Cactus classes,
your test classes: these are your test classes that extend the Cactus 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
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.
If you have the habit of using class variables for the classes to test (as opposed to declaring them within the testXXX() method), you'll also need to put your classes under test in the client side classpath.
If you are using Log4J as the logging framework, you will also need to put a log4j.properties Log4j configuration file in your client side classpath (See the Config Howto tutorial).
---------------------------------------------------------------------
== server side ==
WEB-INF/lib/cactus.jar: the Cactus main jar,
WEB-INF/lib/junit.jar: this is needed because the Cactus XXXTestCase extends the JUnit org.junit.framework.TestCase class.
WEB-INF/classes/
WEB-INF/classes/
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.
If you have several webapps that use cactus you can put all Cactus jars in a place loaded by your container System classloader (provided your container correctly sets the Context classloader). The location is container-dependent; for example for Tomcat 4.x, you can put the jars in TOMCAT_HOME/common/lib.
If you are using Log4J as the logging framework, you will also need to put a log4j.properties Log4j configuration file in your server side classpath (usually in WEB-INF/classes).
-------------------------------------------------------------------------
