Upload
urskeerthi
View
214
Download
0
Embed Size (px)
Citation preview
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)
7/31/2019 Cactus Final
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/7/31/2019 Cactus Final
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/JUnit7/31/2019 Cactus Final
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:
7/31/2019 Cactus Final
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.
7/31/2019 Cactus Final
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.html7/31/2019 Cactus Final
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.html7/31/2019 Cactus Final
8/11
7/31/2019 Cactus Final
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()
7/31/2019 Cactus Final
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.xsl7/31/2019 Cactus Final
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