Develop the Struts Application Unit test

First, the introduction

Test-driven development has also improved the quality of software development while reducing development effort. Unit tests, which are the basis for a set of test strategies, must be comprehensive and easy to build and execute quickly. However, the reliance on the execution environment and the external code of the tested class makes it more complicated to achieve these goals. For example, publishing an application to a container will significantly prolong the code and test cycles, while dependencies on other classes often result in more complex testing and slower test runs.

Integrating two popular test frameworks (Strutstestcase and Easymock) to unit test struts applications will make it easier to build tests and speed up testing. However, there are still some "gaps" between the two frameworks, making it difficult to integrate them ideally. In this article, I'll explore this problem by analyzing two scenarios-an object-oriented scenario and an aspect-oriented scenario. At the same time, I will show how aspect-oriented programming (AOP) can further complement object-oriented programming (OOP) by simplifying solutions to seemingly difficult problems.

Second, integration needs

A typical struts application can demonstrate the dependencies between classes as well as the execution environment in which they are used, because the struts behavior (action) executes within a servlet container and typically invokes other classes to process the request. The Mock object test method helps eliminate unnecessary dependencies. Using the Mockstrutstestcase class inherited from the basic JUnit test set, the Strutstestcase test Framework provides a mock implementation of the servlet container. This is a clear convenience for testing outside the container, thus speeding up the unit test cycle accordingly. On the other hand, another test framework-easymock-further facilitates dynamic simulations (mocks) of collaborative classes. The simulation provided in this framework replaces the real class with a simpler implementation, and the validation logic is added to support unit testing.

It's very clear that combining these two frameworks is a very useful-struts application that can be tested in a very real isolated environment. Ideally, you would use the following steps to implement one of these unit tests:

1. Establish mockstrutstestcase to simulate the servlet container.

2. Use the Easymock to simulate the classes on which the behavior depends.

3. Set expectations for the simulation.

4. Inject the simulation into the behavior of the current test.

5. Continue to test and verify.

Note that the dependency injection performed in step 4 above has enabled the tested struts behavior to interact with a simulated behavior away from its true collaborator. In order to inject the impersonation generated by Easymock into the behavior, you need to access the corresponding instances of these behaviors from within the test class. Unfortunately, there is an obstacle here because we cannot easily implement such access from Mockstrutstestcase.

Third, OOP program

So how do you access instances of behavior from mockstrutstestcase? First, let's analyze the relationship between the controller components of mockstrutstestcase and struts.

The key relationships shown in Figure 1 can potentially lead to a solution to the above problem.

Figure 1: The relationships shown here can create an OOP scenario