StrutsTestCase Simplifies the Development Process

By Sunil Patil
2005-04-28

Cactus Approach

Cactus (in-container) is a popular approach for testing during the integration testing phase. I won't cover Cactus in detail; see Resources for more information.

Setup for Cactus approach
To set up Cactus, copy cactus.1.6.1.jar and aspectjrt1.1.1.jar into your classpath.

Cactus needs two servlets to be configured in your Web application, so you must declare them in the web.xml file, as shown in Listing 13:

Listing 13. web.xml

<servlet>

      <servlet-name<ServletTestRedirector</servlet-name>

      <display-name<ServletTestRedirector</display-name>



<servlet-class<org.apache.cactus.server.ServletTestRedirector</servlet-class>

</servlet>



<servlet>

      <servlet-name<ServletTestRunner</servlet-name>

      <display-name<ServletTestRunner</display-name>

      

<servlet-class<org.apache.cactus.server.runner.ServletTestRunner</servlet-class>

</servlet>



<servlet-mapping>

      <servlet-name<ServletTestRedirector</servlet-name>

      <url-pattern</ServletRedirector</url-pattern>

</servlet-mapping>



<servlet-mapping>

      <servlet-name<ServletTestRunner</servlet-name>

      <url-pattern</ServletTestRunner</url-pattern>

</servlet-mapping>

Next, create a cactus.properties file like the one shown below and put it in the classpath:

cactus.contextURL = http://localhost:9080/sample1

cactus.servletRedirectorName = ServletRedirector

I am using the WebSphere® Studio built-in test environment to run my test cases, so my application will be available on http://localhost:9080/sample1. Be sure to change this path to indicate the location where your Web application is deployed.

Next, create a class to extend CactusStrutsTestCase. Because the same test cases can be used in the mock and Cactus approaches, copy the content of MockLoginActionTest in this class. Build and deploy this application in the container of your choice.

Finally, configure jdbc/ds1 as your data source.

How the STC Cactus approach works

When you are using Cactus for testing an application, you will have to deploy that application in a Web container and run another instance of the Cactus test class as any JUnit test case outside container. When you run the Cactus unit test, it creates and executes an HTTP request for the URL indicated by the cactus.contextURL parameter in your cactus.properties file for every test case method in your class.

In the case of the sample application for executing testDisableUser, it will create and execute a request like this:

http://localhost:9080/sample1/ServletRedirector?Cactus_TestMethod=testDisabledUser&Cactus_TestClass=

  com.sample.test.CactusLoginActionTest&Cactus_AutomaticSession=true&Cactus_Service=CALL_TEST

This request will invoke the ServletTestRedirector servlet deployed as a part of the sample Web application. In ServletTestRedirector, Cactus looks at the name of the test case class from the Cactus_TestClass request parameter and calls its method indicated by the Cactus_TestMethod parameter. Once that method is executed, it returns results as an HTTP response to the Cactus test class, which is executing an outside container.

In addition, when the in-container version of CactusStrutsTestCase gets control (which is CactusLoginActionTest in our case) in the testDisabledUser() method, STC calls the actionPerform() method, which creates an instance of the ActionServlet, ServletContext, and ServletConfig objects. It also wraps the current request and response in a wrapper. Then it calls the doPost() method of ActionServlet, with these wrapped ServletRequest and ServletResponse objects. Struts then processes the request as usual.

With the Cactus approach, you can tell STC to verify forward JSPs by calling the processRequest(true) method, which results in the forward JSP being executed and tested to ensure that it does not throw any compile and run-time errors.

Once control returns from actionPerform(), you can call various verifyXXX() methods to check your assumptions.

Test forward JSP errors
Test to make sure that Success.jsp has no compile time or run-time errors by changing the testVaidLogin() method, as shown in Listing 14:

Listing 14. The testValidLogin() method

public void testValidLogin() throws Exception{



STCRequestProcessor.addMockActionForm("loginForm","com.sample.login.mock.MockLoginActionForm");

	

STCRequestProcessor.addMockAction("com.sample.login.LoginAction","com.sample.login.mock.MockLoginAction");

      processRequest(true);

      setRequestPathInfo("/login");

      addRequestParameter("userName","ibmuser");

      addRequestParameter("password","ibmpassword");

      actionPerform();

      verifyNoActionErrors();

      verifyForward("success");

      }

Also change Success.jsp to make it throw a RunTimeException by adding the following lines:

<%

      throw new RuntimeException("test error");

%>

Now when you run this test case, testValidLogin() will create and execute database queries to check that the user account is not disabled and that the user name and password are valid. The test will then fail, indicating that it got a run-time error while executing Success.jsp.

Tutorial Pages:
» Save Time by Using STC's Mock and Cactus Testing Approaches
» Sample Application
» Using the Mock Object Approach
» Advantages and Disadvantages of Mocking
» Cactus Approach
» Cactus Pros and Cons
» Conclusion
» Resources

First published by IBM DeveloperWorks

Related Tutorials:
» All about JAXP, Part 1
» Make Database Queries Without the Database
» Load List Values for Improved Efficiency
» 2 Ways To Implement Session Tracking
» A Simple Way to Read an XML File in Java
» Develop Aspect-Oriented Java Applications with Eclipse and AJDT