The architectural goals of Struts2 are Separation of Concern, Loose Coupling, Modularization, Convention over Configuration, Testability etc. And here we discussing about Testability. Now a days unit testing has got a crucial role in software development. In the logic of classes, unit tests will assure consistency. To decrease the complication and to increase the robustness, we can implement the unit tests during or before the development.

 

The independent testing of each components of Struts2 are possible . The actions, results, interceptors, object factories, etc are the components of struts2. The most common components are actions and interceptors. So we will take an individual look at these.

 

Actions

 

In the framework, actions are invoked by calling the ‘execute()’ method, or by calling some other methods which will return a ‘String’ value. Let us take an example. The action class given below is for incrementing a number.

 

public class FirstAction {

 

private int num;

 

public int getnum() { return num; }

 

public void setNum( int n ) { num = n; }

 

public String execute() {

 

num =num + 10;

 

return “success”;

 

}

 

 

 

Action instantiation, method calling, and the assertions are the only things that we need at the time of unit test. Because an action is a ‘POJO’. The result of the ‘execute’ method, and the expecting state of action are the two assertions that we need in this example.

 

public class FirstActionTest extends TestCase {

 

 

public void testExecute() {

 

FirstAction action = new FisrtAction();

 

Action.setNum(5);

 

assertEquals(“success”, action.execute());

 

assertEquals(15,action.getNum());

 

}

 

}

 

 

Interceptors

 

During the implementation of interceptors, testing is some more complex. But using some additional help we can overcome this. In the case of interceptors, two scenarios are there.

 

The first scenario is that, when we call an interceptor, it will interact with the ‘ActionInvocation object’. For verifying the logic, we just need to assert the state of interceptor. Testing interceptor through this scenario is exactly same as the actions. Make an instance of the interceptor; make an imitative implementation of the ‘ActionInvocation Object’ with some elements which will be utilized in testing the ‘interceptor’; request(call) the ‘intercept’ method; then make the assertion that the expecting changes. At last the result or the exception will be thrown.

 

The second one is that, when the interceptors interaction is with some other interceptors or with their own environment. Through an ‘ActionProxy’ class, an interaction to the action is need here. For accessing some other environmental objects, which may not be accessed by the interceptor need assertion. Here, for JUnit test it can use ‘XworkTestCase’. And for TestNG tests it can use some classes like ‘TestNGStrutsTestCase’ and ‘TestNGXWorkTestCase’. These all are from the ‘XWork’ library. In the first scenario the ‘intercept() ‘ method on the interceptor will be called. But in the second scenario, it will call the ActionProxy’s execute method.