cactus final

7/31/2019 Cactus Final

1/11

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)


2/11

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

aMock Objectstype 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.
http://www.mockobjects.com/http://www.mockobjects.com/http://www.mockobjects.com/http://www.mockobjects.com/


3/11

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

usesJUnitand 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.
http://en.wikipedia.org/wiki/JUnithttp://cargo.codehaus.org/http://junit.org/http://junit.org/http://junit.org/http://junit.org/http://cargo.codehaus.org/http://en.wikipedia.org/wiki/JUnit


4/11

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:


5/11

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 yoursystem:

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.


6/11

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 offersseveral 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 From an IDEor any tool providing a JUnit integration plugin.

o From a browser, by using the Cactus Servlet Test Runner, which is a special JUnit

Test Runner. Please also check theTomcat quick start tutorialwhich 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
http://jakarta.apache.org/cactus/integration/index.htmlhttp://jakarta.apache.org/cactus/integration/index.htmlhttp://jakarta.apache.org/cactus/integration/index.htmlhttp://jakarta.apache.org/cactus/integration/manual/index.htmlhttp://jakarta.apache.org/cactus/integration/manual/index.htmlhttp://jakarta.apache.org/cactus/integration/howto_ide.htmlhttp://jakarta.apache.org/cactus/integration/howto_ide.htmlhttp://jakarta.apache.org/cactus/integration/integration_browser.htmlhttp://jakarta.apache.org/cactus/integration/integration_browser.htmlhttp://jakarta.apache.org/cactus/integration/howto_tomcat.htmlhttp://jakarta.apache.org/cactus/integration/howto_tomcat.htmlhttp://jakarta.apache.org/cactus/integration/howto_tomcat.htmlhttp://jakarta.apache.org/cactus/integration/howto_tomcat.htmlhttp://jakarta.apache.org/cactus/integration/integration_browser.htmlhttp://jakarta.apache.org/cactus/integration/howto_ide.htmlhttp://jakarta.apache.org/cactus/integration/manual/index.htmlhttp://jakarta.apache.org/cactus/integration/index.html


7/11

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 theClasspath

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

DownloadTomcat4.0 or greater and unzip it in any directory. Let's call this directory [tomcat-

root].

Step 2 : Copy the Cactus jars

Download the Cactus jars from theCactus 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 CactusHttpUnit

integrationyou'll also need to copyhttpunit.jar .

Step 3: Modify Tomcat web.xml
http://jakarta.apache.org/cactus/integration/manual/howto_classpath.htmlhttp://jakarta.apache.org/cactus/integration/manual/howto_classpath.htmlhttp://jakarta.apache.org/cactus/integration/manual/howto_classpath.htmlhttp://jakarta.apache.org/cactus/integration/manual/howto_classpath.htmlhttp://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/http://jakarta.apache.org/cactus/downloads.htmlhttp://jakarta.apache.org/cactus/downloads.htmlhttp://jakarta.apache.org/cactus/downloads.htmlhttp://jakarta.apache.org/cactus/writing/howto_httpunit.htmlhttp://jakarta.apache.org/cactus/writing/howto_httpunit.htmlhttp://jakarta.apache.org/cactus/writing/howto_httpunit.htmlhttp://jakarta.apache.org/cactus/writing/howto_httpunit.htmlhttp://jakarta.apache.org/cactus/writing/howto_httpunit.htmlhttp://jakarta.apache.org/cactus/writing/howto_httpunit.htmlhttp://jakarta.apache.org/cactus/downloads.htmlhttp://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/http://jakarta.apache.org/cactus/integration/manual/howto_classpath.htmlhttp://jakarta.apache.org/cactus/integration/manual/howto_classpath.html


8/11


9/11

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()


10/11

{

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 followingXSLT stylesheet(based on the stylesheet

used by the

Ant task) and drop it in [tomcat-root]/webapps/test . Then, open abrowser

Type

http://localhost:8080/test/ServletTestRunner?suite=TestSampleServlet&xsl=cactus-report.xsl .:
http://jakarta.apache.org/cactus/misc/cactus-report.xslhttp://jakarta.apache.org/cactus/misc/cactus-report.xslhttp://jakarta.apache.org/cactus/misc/cactus-report.xslhttp://jakarta.apache.org/cactus/misc/cactus-report.xsl


11/11

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
http://www.informit.com/articleshttp://www.informit.com/articleshttp://today.java.net/pub/a/today/2004/12/09/testejb.htmlhttp://today.java.net/pub/a/today/2004/12/09/testejb.htmlhttp://jakarta.apache.org/cactus/jira-report.htmlhttp://jakarta.apache.org/cactus/jira-report.htmlhttp://jakarta.apache.org/cactus/jira-report.htmlhttp://today.java.net/pub/a/today/2004/12/09/testejb.htmlhttp://www.informit.com/articles

cactus final

Documents