For Java projects I sometimes use AspectJ for various tasks, but for Android projects I initially decided against using it.
There were various reasons for that:
- The structure of an Android project, and its build process, was already a lot more complicated and slower than for generic Java projects.
- For Android development, only compile time weaving is supported for AspectJ, which makes it less useful.
- The Android Studio IDE does not have support for AspectJ.
However I eventually found some uses for aspects when it comes to testing. Another reason I decided to give AspectJ a try was the availability of Android AspectJ plugins for Gradle. They make integrating AspectJ into the Android build process easier, I use this one.
Using aspects I can weave test code into the application code when required for a particular test. Then when no longer needed, I would just do a normal build without the aspect weaving, and the test code is kept totally isolated in the aspect file.
I found this to be a good alternative to what sometimes happens during testing:
- adding test code for a particular test, and then having to remove it or comment it out afterwards
- adding temporary logging to find a bug, profile some code, etc
What is it Good For, Some Examples
Instead I can weave the crash inducing code into any existing app event I like, e.g a button click, menu click, etc.
Testing exception handling
Write some temporary test code to throw an exception to see if the app handles it correctly.
Have an aspect that throws the exception from any method I choose. I can also have the pointcut advice multiple methods so that the test exception can be thrown from multiple locations.
Testing interactions with external services
(For instance, checking that Google Play services are available.)
Write some test code to simulate the response from the external service that you want to test for. For example, when checking if Google Play services are available then you might want to test that your app correctly handles an unsuccessful result code such as SERVICE_MISSING, SERVICE_VERSION_UPDATE_REQUIRED, etc.
Write an aspect that advices where you call the external service, and have it return the result that you want to test for. It’s up to you whether you want to actually make the call to the external service in the advice using proceed(..) or just have the advice return the result you want.
The Usual Stuff, like Tracing
One of the most common uses of AspectJ is for method tracing, this can be useful for profiling the app or when trying to track down that hard-to-find bug.
Add temporary trace logging to the app code that you think might need profiling or be causing a bug.
Enable tracing of method calls with logging for any or all method calls that I want by adjusting the pointcut for of a tracing aspect. It’s quick and easy to write a pointcut to advice all methods in a class, for example.
There are plenty of examples of AspectJ tracing aspects around, or you can use android tools to generate trace logs by instrumentation.
An AspectJ Example
Let’s start with a common scenario, a service class with a method that makes a network call (presumably to get some data and apply business logic to it). This service method would be called by an activity or fragment in the app.
Note that this example assumes that you are already familiar with how to program in AspectJ native syntax.
I want to test that the activity/fragment correctly handles the situation where there is an error when the service method is called. Here is an aspect that can be used to simulate an exception being thrown on the method call.
In this aspect the pointcut will advice the service method, and throws an exception instead its normal execution. Then we can run the app to check that the Activity / Fragment that calls the service method does handle this error properly.
I can also do this where a reactive library, such as RxJava, is being used in the service class.
This example also shows that the pointcut in the aspect can advice multiple service methods.
Determining When to Build with Aspects (or Not)
Next, we need to weave the aspect in the example into the app code, and then find some way to determine when to do a build with aspects for testing, and when to just do a normal build. In the concluding part of this post, I will show the workflow I use as one way of doing this.
For Testing Only?
As I have mentioned, when using aspects the test/logging code resides in an aspect file that is isolated from the app code and should never get into a release build. However it is always available when I want to run the tests again, and there is no need to worry about forgetting to remove temporary test code after the testing is done.
The use of AOP (Aspect Oriented Programming) for testing only is purely my personal preference. Of course you can just as easily use AspectJ as part of your development process and include aspects in your app code.