Aop@work: Unit testing of aspects-eight new patterns for validating crosscutting behavior

Introduction: AOP makes it easier than ever to write application-specific crosscutting focus tests. To understand why and how to do this, listen to Nicholas Lesiecki about the benefits of testing aspect-oriented code and demonstrate the style of testing crosscutting behavior in AspectJ.

The extensive use of programmer testing over the past five years has been driven by significant productivity and the quality of the code being obtained. However, before aspect-oriented programming (AOP) occurs, it is difficult to write tests for crosscutting behavior, such as security, transaction management, or persistence. Why, then? Because these behaviors are not well modularized. If there are no testable units, it is difficult to write unit tests. With the popularization of AOP, it has become feasible and worthwhile to write tests that are not relevant to the implementation of crosscutting concerns in the target system.

In this article, I'll introduce a set of techniques for testing crosscutting behavior implemented by aspects. Focus on aspects of unit testing, but I also showed other patterns that helped build trust in aspect-oriented applications. As you'll soon see, testing involves many of the same techniques and concepts as test subjects, and has many of the same practices and design benefits.

The writing of this article is based on my experience in AspectJ. Many concepts should be portable to other AOP implementations, but some concepts are language-specific. Please see download the source code below, see Resources for the ASPECTJ and AJDT required to complete the example.

Unit testing for aspect-oriented code

A good automated test set for an application should be as shown in Figure 1: isolating, testing the various classes to form a broad foundation, making the test coverage broad and quickly separating errors. On top of this is an integrated, end-to-end system test that verifies that each unit is capable of coordinating work. If these layers are well-formed and run frequently, they can be combined to increase the degree of trust in the behavior of the application.

Unit tests at the bottom of the pyramid are important, for several reasons. First, they help you create a focus case that is difficult to reproduce in an integration test or that requires tedious steps to reproduce. Second, because they involve less code, they usually run faster (so they can be run more often). Third, they can help you think about the interfaces and requirements of each unit. A good unit test requires loose coupling between cells, which is the condition under which tests are run under test conditions.

Figure 1. Layered Testing

But what about crosscutting behavior? Imagine a customer's request: "Check the caller's security credentials before performing any operations on the ATM class." "Of course you can (and should) write integration tests for this requirement." However, a non-object-oriented development environment makes it difficult to isolate this behavior by unit tests that write "check security before operations" behavior. This is because behavior is mixed into the target system, making it difficult to grasp or use tool analysis. However, if you are developing with aspects, you can represent these behaviors as recommendations (advice) and apply to all operations that match a tangent point (pointcut). Now the behavior can be well represented in a unit, which can be tested in isolation or displayed in the IDE.