Hopefully this entry serves as some search engine friendly documentation on how one might unit test Struts 2 actions configured using Spring, something I would think many, many people want to do. This used to be done using StrutsTestCase in the Struts 1.x days but Webwork/Struts provides enough flexibility in its architecture to accommodate unit testing fairly easily. I’m not going to go over how the Spring configuration is setup. I’m assuming you have a struts.xml file which has actions configured like this:
<struts>
<package namespace="/site" extends="struts-default">
<action name="deletePerson" class="personAction"
method="deletePerson">
<result name="success">/WEB-INF/pages/person.jsp</result>
</action>
</package>
...
</struts>
You also might have an applicationContext.xml file where you might define your Spring beans like this.
<beans>
<bean id="personAction"
class="com.arsenalist.action.PersonAction"/>
...
</beans>
Then of course you also need to have an action which you want to test which might look something like:
public class PersonAction extend ActionSupport {
private int id;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String deletePerson() {
....
return SUCCESS;
}
}Remember than in Struts 2, an action is usually called before and after various other interceptors are invoked. Interceptor configuration is usually specified in the struts.xml file. At this point we need to cover three different methods of how you might want to call your actions.
- Specify request parameters which are translated and mapped to the actions domain objects (id in the PersonAction class) and then execute the action while also executing all configured interceptors.
- Instead of specifying request parameters, directly specify the values of the domain objects and then execute the action while also executing all configured interceptors.
- Finally, you just might want to execute the action and not worry about executing the interceptors. Here you’ll specify the values of the actions domain objects and then execute the action.
Depending on what you’re testing and what scenario you want to reproduce, you should pick the one that suits the case. There’s an example of all three cases below. The best way I find to test all your action classes is to have one base class which sets up the Struts 2 environment and then your action test classes can extend it. Here’s a class that could be used as one of those base classes.
See the comments for a little more detail about whats going on. One point to note is that the class being extended here is junit.framework.TestCase and not org.apache.struts2.StrutsTestCase as one might expect. The reason for this is that StrutsTestCase is not really a well written class and does not provide enough flexibility in how we want the very core Dispatcher object to be created. Also, the interceptor example shown in the Struts documentation does not compile as there seems to have been some sort of API change. It’s been fixed in this example.
public class BaseStrutsTestCase extends TestCase {
private Dispatcher dispatcher;
protected ActionProxy proxy;
protected MockServletContext servletContext;
protected MockHttpServletRequest request;
protected MockHttpServletResponse response;
/**
* Created action class based on namespace and name
*/
protected T createAction(Class clazz, String namespace, String name)
throws Exception {
// create a proxy class which is just a wrapper around the action call.
// The proxy is created by checking the namespace and name against the
// struts.xml configuration
proxy = dispatcher.getContainer().getInstance(ActionProxyFactory.class).
createActionProxy(
namespace, name, null, true, false);
// set to true if you want to process Freemarker or JSP results
proxy.setExecuteResult(false);
// by default, don't pass in any request parameters
proxy.getInvocation().getInvocationContext().
setParameters(new HashMap());
// set the actions context to the one which the proxy is using
ServletActionContext.setContext(
proxy.getInvocation().getInvocationContext());
request = new MockHttpServletRequest();
response = new MockHttpServletResponse();
ServletActionContext.setRequest(request);
ServletActionContext.setResponse(response);
ServletActionContext.setServletContext(servletContext);
return (T) proxy.getAction();
}
protected void setUp() throws Exception {
String[] config = new String[] { "META-INF/applicationContext-aws.xml" };
// Link the servlet context and the Spring context
servletContext = new MockServletContext();
XmlWebApplicationContext appContext = new XmlWebApplicationContext();
appContext.setServletContext(servletContext);
appContext.setConfigLocations(config);
appContext.refresh();
servletContext.setAttribute(WebApplicationContext.
ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, appContext);
// Use spring as the object factory for Struts
StrutsSpringObjectFactory ssf = new StrutsSpringObjectFactory(
null, null, servletContext);
ssf.setApplicationContext(appContext);
//ssf.setServletContext(servletContext);
StrutsSpringObjectFactory.setObjectFactory(ssf);
// Dispatcher is the guy that actually handles all requests. Pass in
// an empty Map as the parameters but if you want to change stuff like
// what config files to read, you need to specify them here
// (see Dispatcher's source code)
dispatcher = new Dispatcher(servletContext,
new HashMap());
dispatcher.init();
Dispatcher.setInstance(dispatcher);
}
}By extending the above class for our action test classes we can easily simulate any of the three scenarios listed above. I’ve added three methods to PersonActionTest which illustrate how to test the above three cases: testInterceptorsBySettingRequestParameters, testInterceptorsBySettingDomainObjects() and testActionAndSkipInterceptors(), respectively.
public class PersonActionTest extends BaseStrutsTestCase {
/**
* Invoke all interceptors and specify value of the action
* class' domain objects directly.
* @throws Exception Exception
*/
public void testInterceptorsBySettingDomainObjects()
throws Exception {
PersonAction action = createAction(PersonAction.class,
"/site", "deletePerson");
pa.setId(123);
String result = proxy.execute();
assertEquals(result, "success");
}
/**
* Invoke all interceptors and specify value of action class'
* domain objects through request parameters.
* @throws Exception Exception
*/
public void testInterceptorsBySettingRequestParameters()
throws Exception {
createAction(PersonAction.class, "/site", "deletePerson");
Map params = new HashMap();
params.put("id", "123");
proxy.getInvocation().getInvocationContext().setParameters(params);
String result = proxy.execute();
assertEquals(result, "success");
}
/**
* Skip interceptors and specify value of action class'
* domain objects by setting them directly.
* @throws Exception Exception
*/
public void testActionAndSkipInterceptors() throws Exception {
PersonAction action = createAction(PersonAction.class,
"/site", "deletePerson");
action.setId(123);
String result = action.deletePerson();
assertEquals(result, "success");
}
}The source code for Dispatcher is probably a good thing to look at if you want to configure your actions more specifically. There are options to specify zero-configuration, alternate XML files and others. Ideally the StrutsTestCaseHelper should be doing a lot more than what it does right now (creating a badly configured Dispatcher) and should allow creation of custom dispatchers and object factories. That’s the reason why I’m not using StrutsTestCase since all that does is make a couple calls using StrutsTestCaseHelper.
If you want to test your validation, its pretty easy. Here’s a snippet of code that might do that:
public void testValidation() throws Exception {
SomeAction action = createAction(SomeAction.class,
"/site", "someAction");
// lets forget to set a required field: action.setId(123);
String result = proxy.invoke();
assertEquals(result, "input");
assertTrue("Must have one field error",
action.getFieldErrors().size() == 1);
}This example uses Struts 2.0.8 and Spring 2.0.5.
