CodePro can now generate tests for the Struts2 Framework ( struts.apache.org). Struts2 is an elegant, extensible framework for creating enterprise-ready Java web applications. The framework is designed to streamline the full development cycle, from building, to deploying, to maintaining applications over time.
CodePro recognizes and generates tests for classes which implement the
com.opensymphony.xwork2.Action
interface, or extends the
com.opensymphony.xwork2.ActionSupport
class.
Let’s start out with a simple Create Message example of a Struts2 ActionSupport class:
public class CreateMessageAction extends ActionSupport {
private String guest;
private String message;
public String execute() {
Message msg = new Message();
msg.setGuest(guest);
msg.setMessage(message);
msg.setWhen(new Date());
return SUCCESS;
}
public String getGuest() {
return guest;
}
public void setGuest(String guest) {
this.guest = guest;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
In order to generate tests for this controller, right click on the class in the Package Explorer and choose
CodePro Tools > Generate Test Cases. This will create and open a new test case called
CreateMessageActionTest
.
public class CreateMessageActionTest extends TestCase {
/**
* Run the String execute() method test.
*
* @generatedBy CodePro at 12/18/08 2:45 PM
*/
public void testExecute_1()
throws Exception {
CreateMessageAction fixture = new CreateMessageAction();
fixture.setMessage("a");
fixture.setGuest("a");
String result = fixture.execute();
// add additional test code here
assertEquals("success", result);
}
}
Like CodePro’s normal test generation, we create a fixture of the class under test, execute the method under test, and make assertions on the results.
When generating unit tests for Struts2 Actions, it is important to test them in isolation of the rest of the classes in the application. In a Struts application, your action class may depend on other services to perform its work. These services could access databases, send emails to customers, or generally perform work that you don’t really want to do in the context of a unit test. In order to isolate your action, when CodePro sees a service it will create a mock of that service in the test. So if you have an
PortfolioServiceInterface
interface and an
PortfolioServiceImpl
concrete implementation, instead of creating an instance of
PortfolioServiceImpl
(which would modify an actual database), CodePro will use EasyMock to create a mock implementation of
PortfolioServiceInterface
.
MyAction fixture = new MyActionr();
PortfolioServiceInterface service = EasyMock.createNiceMock(PortfolioServiceInterface.class);
fixture.setPortfolioService(service);
fixture.execute();
These mock objects will allow any method to be called. If a method has a return type, the mock object will by default return
null
or
0
as appropriate. In order to return other values, the user must set up the proper expectations on the mock object, and then switch the mock over to replay mode. For example:
MyAction fixture = new MyAction();
PortfolioServiceInterface service = EasyMock.createNiceMock(PortfolioServiceInterface.class);
EasyMock.expect(service.persist("testPortfolio")).andReturn((boolean) true);
EasyMock.replay(service);
fixture.setPortfolioService(service);
fixture.execute();
For more information on using EasyMock mock objects, see easymock.org.