This article is focused on which approach we should choose for unit testing against Struts action, I hope it will give you some help when you have question on how to do unit testing against the controller in MVC.
OK, let's begin!
In container? Mock objects?
There are two kinds of testing, one is in-container and the other is do testing with mock objects. Generally speaking, it was considered to be more really and truly unit testing when you do testing with mock objects, especially when you do testing against java source files which should be run in J2EE container, but as our code become complex which contain more layers, the controller(Struts) will have more depends on the other layer which may be EJB service or other business objects, so when you do unit testing against view layer(here is Struts), it will be a huge work for you to construct the mock objects and also it will have more source code changed as you apply mock objects in your source code, the following is a simply description which describe the classic three layers project, and also considerd to be the most common type of web based project.
e.g. the Struts action class first call the EJB factory to get an EJB service, and then ask this EJB service to do the work according to the business logic and return the value we need, with the value EJB service returned the action class can choose which page to redirect or do some other data processing ,this could be the classic three layers type, maybe the most common type project we used in our project.
Therefore, it may not be the best choice for every web based project to apply mock objects unit testing. In the case that Struts action class is close tied with your business object, in-container testing may be an alternate choice for you, because it save your time to write mock objects and the workload to apply the mock objects into your source files but supply the same testing resluts.
In-container testing sounds good, but when you do testing in this style, it first assume that the depended business service classes used in our Struts action must be verified, if the depended service classes have some defect that happen to be met when we run in-container testing, it will take more time to find which cause the error indeed.
But I think if we have a complete testing procedure, which cover the service layer and the controller, the service layer have already been verified properly, in-container testing is really the best choice for you to use for testing action class. For project in practice, the Struts action is more or less close tied with other layer, it's not realistic to spend more time on writing mock objects or modifying your source code to apply the mock objects. In my opinion, the recommended solution is that you should focus on Struts layer testing, if the Struts action code is close tied with other service layer which I mean is that there may be only one execute() method in every Struts action take charge for the whole business logic, you should use in-container testing, let other unit testing stuff take charge for service layer which may be out of container unit testing against EJB, in this way you can write your test case at your pleasure, forget the depended layers for a while, the container will take care for other layers for you, and also it will save you lots of time for writing mock objects, the container will give you the real objects instead of mock objects.Mock object testing is more often used for the simple Struts action or the case that it could be influenced by the container when you do unit testing against Struts action.