Rethinking Android Unit Testing

After using Robolectric for a while I was looking for a different approach to do unit testing for Android.

While Robolectric met a lot of my requirements I had the need for a powerful mocking framework and decided to use PowerMock(ito). It's a really powerful framework but I wasn't able to use it together with Robolectric since both do a lot of classloader and byte code transformation magic.

So I decided to just run the test with "android.jar" from the SDK on the classpath and forget about Robolectric but instead mock the platform API calls with PowerMock(ito).

Unfortunately it turned out that this wasn't as easy as it sounds. So I decided to use Javassist to do some byte code manipulation to the android.jar before using it for unit testing. The problem with the original android.jar was that each and every method throws a "Sub"-runtime exception and PowerMock(ito) wasn't able to mock super-calls. (imagine an activity as the class-under-test which must call super.onCreate() in it's onCreate() implementation. Since it's not possible to mock the super.onCreate() you are out of luck)

This approach turned out to be the silver bullet of In-JVM Android unit testing for me.

Thanks to Javassist the transformation of the android.jar was a simple task and now I'm able to use the full potential of PowerMock(ito) to test Android code in Eclipse and during CI builds - including code coverage and all the other fancy stuff.


  1. Generally If I should i know it will be an enjoyable practical experience, with a little luck I won't have to return soon but. Thanks!

  2. I am going to be without doubt getting far more information at SOSav Ersatzteile Smartphones. Everything was greatest. Those things, the best time, the transport, though the price of those things can be quite a tiny cheaper. But I am nevertheless delighted