Server-side testing tool - Cactus Introduction and examples


Cactus is a simple, easy to use server-side testing framework that allows developers to easily test the server-side program.

Junit Cactus is an extension, but it is a little different, and Junit.Cactus test is divided into three different test categories, JspTestCase, ServletTestCase, FilterTestCase, rather than to a Junit TestCase.

Cactus test code with server and client both part of their work.In the test server-side applications, Cactus and Junit compared to what advantage?

General EJB or servlet, jsp are running on the server, if you use the junit test, your test is in the client, which makes the operating environment and test environment are in different system environments, this sometimes different testresults.

EJB2.0 in the Local interface, does not allow remote calls.Not tested with Junit, and Cactus in the redirector on the server side, can be run in a EJB container, which makes it possible to directly access the Local Interface.

In an EJB application, generally there are some front-end application to access the EJB, for example: jsp, servlet, javabean.This means that you need a testing framework to test the front-end components.Cactus provides all the components of the testing methods.

Cactus and ant very good together, can easily complete the automated testing and reduce a lot of workload.

First, the working principle

1, JUnit Test Runner called YYYTestCase.runTest (), this method to find beginXXX (ServletTestRequest)

2, YYYTestCase.runTest () opens a connection to the Redirector Proxy for HTTP

3, Redirector Proxy proceed as follows

Create an instance of Test class

Create some Server object (HttpServletRequest, ServletConfig, ServletContext) of the Cactus wrapper if necessary, create an HTTP Session

4, Redirector

Proxy through the Reflection, the implementation of Test class setUP (), testXXX (), tearDown ()

5, testXXX () method call Server side classes, and through JUnit's assert API to validate the test results

6, if the test fails, testXXX () method throws an exception, Redirector Proxy will catch exceptions

7, Redirector Proxy exception to the client returns the information, JUnit will print out the information

8, if no exception, YYYTestCase.runTest () to find and implement endXXX (HttpURLConnection), here you can use JUnit asserts check the returned HTTP Header, servlet output stream

Servlet Redirector Proxy

HTTP client opens two connections, one for the implementation of the test and get back the Servlet output stream; the other to retrieve test results.Test results are stored in a variable, and placed into the ServletContext for the second connection back.

JSP Redirector Proxy

Client opens two connections, one for the implementation of JSP Redirector connection test, get back JSP output stream; second connection Servlet Redirector back test results.The same test results are stored in a variable, and placed into the ServletContext for the second connection back.




[Next]



Second, the configuration

client-side


cactus.properties
Configuring Server-side steering address
cactus.servletRedirectorURL =
http://localhost:8080/test/ServletRedirector/
(Note: at the end of "/")
cactus.jspRedirectorURL =
http://localhost:8080/test/JspRedirector/
cactus.filterRedirectorURL =
http://localhost:8080/test/FilterRedirector/


log_client.properties

Configuring log4j

Has been included in the cactus.jar a really province log_client.properties, log_server.properties file.

If you want to provide their own log_client.properties files on the classpath, this file should, and must be placed before cactus.jar.

server-side

web.xml

For client-side cactus.properties above match, you need to deploy a server-side application named test, and write a configuration file web.xml, instantiated as follows:




FilterRedirector

org.apache.cactus.server.

FilterRedirector





FilterRedirector

/ FilterRecirector /



The same configuration ServletRedirector, JspRedirector class and URL, so special is JspRedirector class configuration is:


JspRedirector

...(/ someDir) / jspRedirector.jsp



...

...






Note: If you use JspRedirector (ie inherited JspTestCase), you have to jspRedirector.jsp copied to a directory (web.xml in someDir).jspRedirector.jsp file in the sample / web / test, as a proxy call server-side unit tests, documentation example:
<% @ Page import = "org.apache.cactus.server .*" session = "false"
%>

<%

JspImplicitObjects objects =

new JspImplicitObjects ();

objects.setHttpServletRequest (request);

objects.setHttpServletResponse (response);

objects.setServletConfig (config);

objects.setServletContext (application);

objects.setJspWriter (out);

objects.setPageContext (pageContext);



JspTestRedirector redirector =

new JspTestRedirector ();

redirector.doGet (objects);

%>


log_server.properties

In cactus.jar, if you want to customize the best package to the modified log_server.properties to cactus.jar, cover with the original file.

Third, how to write test cases (TestCase)

Write a Test Case of the steps:

1, Import
import org.apache.cactsu .*;
import junit.framework .*;



[Next]



2, Extends a cactus TestCase
public class TestSampleServlet
extends Servlet / Jsp / FilterTestCase
{


3, the standard JUnit methods

1) constructor
TestSampleServlet (String theName)
{
super (theName);
}
/ / TheName is the Test of the Name


2)
main (String [])
/ / Start a JUnit Test Runner
junit.ui.TestRunner.main (new String []
{
TestSampleServlet.class.getName ()
});


3)
suite ()
/ / Static method, the return value Test
return new TestSuite (TestSampleServlet.class)


4, setUP (), tearDown ()

5, testXXX ()

An example:
public void testXXX ()
{
SampleServlet servlet = new SampleServlet ();
session.setAttribute ("name", "value");
servlet.doSomething (request);
assertEquals ("something", result);
assertEquals ("otherValue",
session.getAttribute ("otherName"));
}


6
beginXXX (WebRequest) / / optional

WebRequest all set in the HTTP related parameters are:
setMethod (String)
setAutomaticSession (boolean)
setURL (...)
addParameter (String, String)

Then, you can testXXX () method call HttpServletRequest's getQueryString (), getHeader (), etc. are.

Note: This method is the implementation of the client side, the first and testXXX () method; So, do not attempt to access any of the class variables that represent API objects (their values are null).endXXX () are the same.
endXXX (HttpURLConnection) / / optional

For ServletTestCase, provides the following implicit objects:
request C org.apache.cactus.
server.HttpServletRequestWrapper
response C javax.servlet.
http.HttpServletResponse
config C org.apache.cactus.
server.ServletConfigWrapper


Package config 2 objectives:

Provide additional methods, HttpConfigWrapper 2 more methods than javax.servlet.ServletConfig
setServletName (String)
setInitParameter (String, String)
/ / And set in the web.xml has the same effect


ServletContext can return packaging

session C javax.servlet.http.HttpSession

Tip 1: If you use any methods inherited from javax.servlet.GenericServlet (for example: log (), getServletConfig (), etc.), then you need to call the servlet's init (ServletConfig) method to an instance of ServletConfig object.For example:
public void testXXX ()
{
MyServletToTest servlet =
new MyServletToTest ();
servlet.init (config);
... Servlet.someMethodToTest ();
}

For JspTestCase, provides the following implicit objects:
request C org.apache.cactus.
server.HttpServletRequestWrapper
response C javax.
servlet.http.HttpServletResponse
config C org.apache.
cactus.server.ServletConfigWrapper