Test flexibility for ASPECTJ and mock objects

To enhance unit testing with "test-only" behavior

Introduction: Programmers who combine unit tests in the development process understand the benefits of doing so: the code is simpler, dares to refactor, and is faster. But even the most persistent unit testers can be less confident when they encounter a class that is dependent on the system state for the test behavior. Nicholas Lesiecki, a respected Java programmer and leader of the XP community, will introduce the problem of isolation around test cases and show us how to develop accurate and robust unit tests using mock objects (mock object) and AspectJ.

Recently, the focus on extreme programming (Extreme PROGRAMMING,XP) has expanded to one of its most portable applications: unit testing and initial test design. Because the software studio has started using XP development methods, we can see that, because of a comprehensive suite of unit testing tools, many developers have improved the quality and speed of development. But well-written unit tests are time-consuming and laborious. Because each unit works with other units, writing unit tests may require a lot of setup code. This makes the tests more expensive, and in certain cases, such as when the code is the client of the remote system, such tests may be almost impossible to implement.

In XP, unit testing compensates for deficiencies in integration and acceptance testing. The latter two types of tests may be performed by an independent team, or as an independent activity. But unit tests are written at the same time as the code to be tested. In the face of looming deadlines and the pressure of a headache unit test, we are likely to write a test at random or give up the test altogether. Because XP relies on a positive motivation and self-sufficiency habit, so XP process (and project!). The best interest is to keep the tests focused and easy to write.

Background required

The focus of this article is on AspectJ unit testing, so the article assumes that you are familiar with basic unit test methods. If you are unfamiliar with AspectJ, it may be helpful to read my introduction to AspectJ before proceeding (see Resources). The AspectJ method here is not very complicated, but it takes a little time to get used to aspect programming. To run the example, you need to install ANT on the test machine. However, you do not need to have any special Ant expertise (beyond the technology required for basic installation) to run the sample.

Imitating objects can help you solve this dilemma. Mock object testing replaces domain-related things with mock implementations that are used only for testing. However, this strategy does in some cases create technical challenges, such as unit testing on remote systems. AspectJ is a aspect-oriented extension of the Java language, which allows us to replace the test-only behavior in places where traditional object-oriented methods fail, so that unit tests can be done in other ways.

In this article, we will discuss a common situation where it is difficult and desirable to write unit tests. We will start by running unit tests for a client component of an EJB-based application. We will use this example as a starting point to discuss some of the issues that may arise when unit testing is performed on a remote client object. To address these issues, we will develop two new test configurations that rely on AspectJ and mock objects. When you see the end of the article, you should have an understanding of common unit test problems and their solutions, as well as a preliminary understanding of some of the interesting possibilities offered by AspectJ and mock object testing.

Unit Test Example

The example consists of a test of an EJB client. Many of the issues raised in this case study apply to the code that invokes the WEB service, the code that invokes JDBC, and even the "remote" part of the local application that is invoked through the virtual package.

The server-side Customermanager EJB performs two functions: it locates the customer name and registers the new customer name with the remote system. Listing 1 shows the interface that Customermanager exposes to the client:

Listing 1. Customermanager Remote Interface

public　interface　CustomerManager　extends　EJBObject　{
　　　 /**
　　　 *　Returns　a　String[]　representing　the　names　of　customers　in　the　system
　　　 *　over　a　certain　age.
　　　 */
　　　 public　String[]　getCustomersOver(int　ageInYears)　throws　RemoteException;
　　　 /**
　　　 *　Registers　a　new　customer　with　the　system.　If　the　customer　already
　　　 *　exists　within　the　system,　this　method　throws　a　NameExistsException.
　　　 */
　　　 public　void　register(String　name)
　　　　 throws　RemoteException,　NameExistsException;
}