An Aspect-Oriented Unit Testing Solution
As software systems become more complicated, the problem of testing them effectively gets harder. Unit testing is a methodology for testing small parts of an application independently of whatever application uses them. It is time consuming and tedious to write unit tests, and it is especially difficult to write unit tests that model the pattern of usage of the application they will be used in. It is common for an application to expose a bug in a module that the unit tests for that module missed entirely. A better approach is to monitor the application as it runs its regression tests, and to capture the events at the boundaries of the module of interest. This log of events can then be replayed to a test harness that exercises the module independently of the environment in which it was originally tested.
A system for implementing such a strategy would need to analyze the application code, identify the sites that constitute the boundaries of the module, and then essentially rewrite the application code to capture occurrences of such events and log them to a file. Such a system would be highly complicated and expensive to produce. Fortunately, we can leverage work done in a field of computing that addresses just this issue-the field of Aspect-Oriented Programming.
Aspect-Oriented Programming (AOP) addresses the problem of separation of concerns in programs. An aspect is defined as a crosscutting property of a program. For example, an aspect might be the property that states that all exceptions must be logged to a file. Traditional programming methodologies require that the code to implement the aspect be replicated everywhere the aspect should be enforced. This makes it tedious and time consuming to do in the first place, or to modify after the fact. AOP is novel because it allows the user to specify the aspect in one location, independently of the target code. An aspect weaver is software that then merges the aspect with the original code.
The unit test problem is one that is well suited to AOP. Roughly speaking, the aspect would specify that all events at the boundary of a module, e.g., a call to a method of a class in that module, would be logged to a file. The weaver would insert the code to do the logging into the application. Then, when the application is run with its own test data, its input and output to the module would be captured.
The pre-eminent tool for doing AOP is AspectJ, which is being developed by Gregor Kiczales (the inventor of AOP) and his team at Xerox PARC. Under an NSF SBIR grant, GrammaTech is studying how AspectJ can be used to develop a tool to capture an application's interaction with a module, then to allow that interaction to be played back to the module to confirm that its behavior is identical.