Master of Technology In (Software Engineering)

JNTU-SIT Campus, Hyderabad-500085,Andhra Pradesh, India, 2011. Seminar topic on:

CACTUS

Presented By
KEERTHI (11301D2507) SHIREESHA (11301D2517) ATHAR (11301D2503)

AIM:
The intent of Cactus is to lower the cost of writing tests for server-side code and provide a simple unit testing framework focused on server side java code which tries to cover all J2EE component models and potentially other type of components

Type of testing: Unit Testing. The Jakarta Cactus project is an extension of JUnit that also
supports white box testing of server-side code that runs in Tomcat. Unit Testing is a level of the software testing process where individual units/components of a software/system are tested. The purpose is to validate that each unit of the software performs as designed.A unit is the smallest testable part of software. It usually has one or a few inputs and usually a single output. In procedural programming a unit may be an individual program, function, procedure, etc. In object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class. (Some treat a module of an application as a unit. This is to be discouraged as there will probably be many individual units within that module.Unit testing frameworks, drivers, stubs and mock or fake objects are used to assist in unit testing. Different kinds of unit tests There are several kinds of unit testing frameworks. We categorize them in 3 types: 1. Type 1: code logic unit testing. Probably the best strategy for these tests is to use a Mock Objects type framework. 2. Type 2: integration unit testing. Cactus is typically in this category. 3. Type 3: functional unit testing. These unit tests will let you test the returned values from your server code. Ideally we would use 3 different frameworks just to unit test your code Then you have to think about acceptance testing, system integration testing, ... Cactus was developed to fit Type 2 but also to be a very good compromise for types 1 and 3.

Product manufacturer (history):

The Jakarta Cactus project announced the new 1.8.1 version on January 18, 2009. Version 1.8.1 still does not support JUnit 4.x, although a workaround of sorts is documented As of 1.8, Cactus uses Cargo for all server-related manipulation. As of 08/05/2011, cactus has been retired.

Introduction:
Cactus is a simple test framework for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters ...).The intent of Cactus is to lower the cost of writing tests for server-side code. It uses JUnit and extends it. Cactus implements an in-container strategy, meaning that tests are executed inside the container.

Description
In its basic form, Cactus is a layer on top of JUnit that allows for test code to be run in both a client space and a server space. Thus, a test can initiate a call from the client, test the server-side code, and review the results. One of the major benefits of Cactus is that it handles all the session creation, request creation, and response creations

The Cactus Ecosystem is made of several components:

The Cactus Framework: This is the heart of Cactus. It is the engine that provides the API to write Cactus tests. The Cactus Integration Modules: They are front ends and frameworks that provide easy ways of using the Cactus Framework (Ant scripts, Eclipse plugin, Maven plugin, ...). The Cactus Samples: They are simple projects that demonstrate how to write Cactus tests and how to use some of the Integration Modules.

General design features:

Cactus gives you a very good confidence that your code is going to run fine on the server it will be deployed on (thanks to Cactus in-container approach that executes the test inside the container),

Cactus let you test container interactions. This is essential in a world where containers are providing more and more features for their components every day,

Cactus let you test and automate the deployment process to your server (using powerful Integration Modules with different build tools and IDEs),

Cactus does not mandate any change to your classes to test, although it helps think about writing better code and do some refactoring,

Cactus provides a good middle ground in term of test granularity: too fine-grained tests are hard to write (like Mock Objects tests that completely simulates the domain objects and focus exclusively on unit testing your code logic) and need complementary tests.

Current scope and status of Cactus

Cactus has the ability to unit test the following kind of components running in a Servlet/EJB container:

How Cactus Works

Cactus uses a proxy mechanism to run test cases at the client, and redirect the requests to a copy of the test case inside the server container

Structure of a Cactus test

to verify the HTTP begin(), end(): executed on the client side before and after each test case setUp(), tearDown(): executed on the server side before and after each test case testXXX(): a test method, to be executed within the server container beginXXX(WebRequest request): a method to be executed on the client immediately before testXXX().The parameter is used to set up the request to be passed to the server. endXXX(WebResponse theResponse ): a method to be executed at the client immediately after testXXX(). This is used response from the user

System Requirements
In order to run Cactus tests you need to have the following software already installed on your system:

Java Virtual Machine A Java 1.2 or greater compatible virtual machine must be present. Note that all servlet engines require a JVM to run so if you are already using servlets you already have one installed.

Servlet/J2EE Engine A Servlet 2.x/J2EE 1.x compliant servlet engine for running your Cactus tests must be present.

Installing Cactus
There is not really an installation of Cactus per see, as Cactus is not an application but a framework. However you do need to understand how it integrates in your working environment. In order to simplify this integration Cactus offers several integration modules. Thus, installing Cactus simply means picking an integration module and learning how to configure and use it.

Starting Cactus tests

The Cactus tests are started using a JUnit Test Runner. There are several integration clients you can use for executing these test runners:

Manually. This means that you need to deploy your code and tests into your container and start this container by yourself. Then you can execute the tests by running a standard JUnit test Runner. For example, you can start the tests:
o

From the java command line, calling the main() method of a JUnit Test Runner. For example, running the JUnit Swing Test Runner: junit.swingui.TestRunner.main [test case class]

o o

From an IDE or any tool providing a JUnit integration plugin. From a browser, by using the Cactus Servlet Test Runner, which is a special JUnit Test Runner. Please also check the Tomcat quick start tutorial which is a step by step tutorial describing how to deploy Cactus tests in Tomcat and how to execute them through a browser.

Testing In Cactus

There are 2 ways of packaging Cactus &execute Cactus tests on your application:

By putting all Cactus jars in your WEB-INF/lib directory, as described in the Classpath Tutorial,

By putting the Cactus jars in your container classpath so that Cactus will load them using the container Context class loader. This tutorial will describe this strategy as it is the less intrusive one and provides reuse of Cactus jars across several webapps.

Step 1: Install Tomcat Download Tomcat 4.0 or greater and unzip it in any directory. Let's call this directory [tomcatroot] . Step 2 : Copy the Cactus jars Download the Cactus jars from the Cactus download page. They are located in the lib/ directory in the zip. Copy the following jars to [tomcat-root]/common/lib :

cactus.jar commons-httpclient.jar commons-logging.jar junit.jar aspectjrt.jar

This is the minium set of jars needed. If later on you wish to use the Cactus HttpUnit integration you'll also need to copy httpunit.jar . Step 3: Modify Tomcat web.xml

Edit [tomcat-root]/conf/web.xml and add the following at the beginning of the file, after the <webapp> tag: <servlet> <servlet-name>ServletRedirector</servlet-name> <servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class> <init-param> <param-name>param1</param-name> <param-value>value1 used for testing</param-value> </init-param> </servlet> <servlet> <servlet-name>ServletTestRunner</servlet-name> <servlet-class>org.apache.cactus.server.runner.ServletTestRunner</servlet-class> </servlet> <servlet-mapping> <servlet-name>ServletRedirector</servlet-name> <url-pattern>/ServletRedirector</url-pattern> </servlet-mapping>

<servlet-mapping> <servlet-name>ServletTestRunner</servlet-name> <url-pattern>/ServletTestRunner</url-pattern> </servlet-mapping> Warning: Be careful when you modify the global Tomcat web.xml file. If later on you wish to use the Cactus Ant integration and more specifically if you use the <cactifywar> Ant task, you may run into problems. The <cactifywar> task automatically adds the needed Cactus redirectors (thus they'll be added twice leading to an error. Step 4: Creating a sample applicaton to test

We're now going to create a very very simple application to server so that we can unit test it. First, create the following directory structure: [tomcat-root]/webapps |_ test |_ WEB-INF |_ classes Then, create the following SampleServlet.java java source file, compile it and copy the resulting .class file in [tomcat-root]/webapps/test/WEB-INF/classes . import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; public class SampleServlet extends HttpServlet { public void saveToSession(HttpServletRequest request) { String testparam = request.getParameter("testparam"); request.getSession().setAttribute("testAttribute", testparam); } } You'll notice that this isn't even a finished servlet ! However, this shows that you can start testing your code with Cactus even before you have finished writing it completely We're now read to create our first Cactus test case. Create the following TestSampleServlet.java java source file, compile it and copy the resulting .class file in [tomcat-root]/webapps/test/WEB-INF/classes . Test case import junit.framework.Test; import junit.framework.TestSuite; import org.apache.cactus.ServletTestCase; import org.apache.cactus.WebRequest; public class TestSampleServlet extends ServletTestCase { public TestSampleServlet(String theName) { super(theName); } public static Test suite()

{ return new TestSuite(TestSampleServlet.class); } public void beginSaveToSessionOK(WebRequest webRequest) { webRequest.addParameter("testparam", "it works!"); } public void testSaveToSessionOK() { SampleServlet servlet = new SampleServlet(); servlet.saveToSession(request); assertEquals("it works!", session.getAttribute("testAttribute")); } } Step 5: Run the test Time to enjoy our hard work ! Start Tomcat by running [tomcat-root]/bin/startup.bat (for windows) or [tomcat-root]/bin/startup.sh (for unix). Open a browser and point it at http://localhost:8080/test/ServletTestRunner?suite=TestSampleServlet You should see:

Step 6: If we want HTML instead of XML Grab the following XSLT stylesheet (based on the stylesheet used by the <junitreport> Ant task) and drop it in [tomcat-root]/webapps/test . Then, open a browser Type http://localhost:8080/test/ServletTestRunner?suite=TestSampleServlet&xsl=cactus-report.xsl .:

Conclusion: Cactus provides a middle ground that provides a high confidence that your code will run when deployed .It allows for the testing of server-side code without starting up a container externally or having to mess with the production code. With the two separate jvm instances that it creates, a full client/server environment can be simulated in the tests. By executing a portion of the test code inside of the server jvm space, Local Interfaces can be tested where normal JUnit tests can test only the Remote Interfaces of an EJB. Resources: links http://www.informit.com/articles http://today.java.net/pub/a/today/2004/12/09/testejb.html http://jakarta.apache.org/cactus/jira-report.html