Testing third-party libraries can be even more difficult to test. If your application is supposed to log something to the console or file how do you test for that? If your application is supposed to send an e-mail on a certain event how do automate the testing to capture the e-mail content? As with third-party systems you can create a proxy to the third-party library and have all input to the APIs done via the implementation of an interface. But unfortunately the problem is the same. You bloat your application with extra code and complexity for the sole purpose of testing but with no benefits or usefulness during production runs.

A way around the interface proxy testing trap that I recently discovered is by incorporating aspects into my testing. This article will show you how to use runtime aspect weaving to proxy the behavior of third-party libraries and systems without adding this code to the production application and without disrupting the original execution flow of the program.

Introduction to Aspects
This article is by no means a tutorial on Aspect Oriented Programming (AOP). But to understand how to incorporate aspects in your unit testing it's necessary to understand what aspects are and a few basic concepts associated with them.

AOP is a complement to object-oriented programming (OOP) and gives the programmer the ability to think about his program structure in a different way. In OOP your main unit of work is the class. In AOP you main unit of work is the aspect. Aspects let you weave in functionality across one or more classes without having to change the class itself. This weaving of functionality is called crosscutting. An example of crosscutting is the incorporation of some common function across all classes that throws an exception. For instance, you can apply an aspect to your program that on throwing a SQLException you would test the database connection before processing the exception. If the database was down you might want to try to re-establish the connection in case the application has a 24x7 requirement.

When coding your aspect you must tell it when it is to be invoked. Join point is the term used to specify the point when the aspect is invoked. The Join Point might be the execution of a method or the handling of an exception. To specify the Join Point in an aspect you declare a pointcut. The pointcut is a predicate that matches join points. In other words, the pointcut is a piece of code that matches the method or exception that you want the aspect to intercede upon. This matching can be as specific or as general (using wildcards) as you wish.

When your aspect encounters a join point, as specified by your pointcut, the code that the aspect executes is determined by the aspect's advice. Advice is the action taken at a particular Join Point. Different types of advice can be specified. If you want some code executed before the intercepted class's method is executed you use "before" advice. If you wanted it executed after then you use "after" advice. If you want code to be executed before and after the intercepted class's code is executed then you use "around" advice. There are many different kinds of advice at the AOP programmer's disposal.

Finally when you're ready to execute your application you must weave your aspects with your objects. Weaving is the linking of aspects with other application types or objects to create an advised object. Weaving can be done at compile time, load time, or runtime. When weaving is done at compile time (such as using the AspectJ compiler) the actual bytecode generated is modified. Since we want to avoid adding "test-only" code to our application we will not use compile-time weaving but instead use an aspect framework that utilizes runtime weaving. There are additional concepts in Aspect Oriented Programming but I have covered what you'll need to know for the testing technique demonstrated in this article.

There are many aspect frameworks available for Java. The plethora of frameworks pays tribute to the fact that aspects are becoming more and more useful in a variety of different environments. Some of these frameworks are AspectJ, JBossAOP, and Spring AOP. The framework used in this article is Spring AOP. Even Spring AOP gives you a couple of aspect frameworks from which to choose. You can use either AspectJ annotations (developed for Spring by the AspectJ community) or Spring AOP.

I chose to use AspectJ annotations (@AspectJ) because in @AspectJ there's a single module, the Aspect, in which all the requirement implementation is implemented. In Spring AOP the knowledge of how a requirement is implemented is split. Another limitation of Spring AOP is that a proxy class incorporating the aspect must be created. The problem with this is that the only time the aspect is invoked is via the direct invocation of the proxy class. If you directly call a method on the proxy class that incorporates the aspect then the aspect is invoked. If the same method is indirectly called by another method that doesn't have access to the proxy class the aspect is not invoked. @AspectJ lets you to declare the aspect's join points and advice in one module and allows for runtime weaving so no matter when, where, or how the advised class is called, the aspect is invoked.

Testing the Untestable
Untestable is probably too harsh a word but aspects do give you a nice method of testing components in your code that aren't obvious and straightforward to test. Let's get to it.

The best way I learn something is by seeing an example. Listing 1 shows the code for a class I call Weather. The Weather class is constructed with the name of a city and the name of a country. In the constructor the Weather object invokes a Web Service to determine if weather data is available for the given city and country. If it is then the Weather instance is successfully constructed and the user of the object can call getTheLatestWeather() to retrieve the current weather conditions for the particular city and country.