Android: Unit testing Android applications with Robolectric and Mockito

Question

I have a Java library that uses a few things from the Android APIs. I'd like to use Mockito to write unit tests for this library.

Is there a way I can go about this?

Mockito doesn't play nice on the Dalvik VM, see this post: Using Mockito with Android virtual machine

UPDATE:

Since this post I've discovered Robolectric, and I've had the opportunity to work out of Pivotal Labs and make some small contributions to this library. I would recommend using this over the Android testing framework/mockito. Also, you're free to use Robolectric AND Mockito, but the shadow objects in Robolectric make Mockito unnecessary for most use cases.

The problem with trying to unit test Android is that the Android library that you build on has every method stubbed out to either throw a stub exception, or return null. If you want to test your app and want any Android behavior you are out of luck, unless you use Robolectric which rewrites the byte-code on the fly when the classes load, and injects a shadow object that simulates the behavior.

UPDATE 2:

It's been a while and things have changed. Many of the Shadow classes in Robolectric have been replaced with the real Android classes. The real Android jars are now used and Robolectric only loads Shadow classes for a much smaller set of things. This is even more of a reason to use Robolectric for your Android testing.

Answer 1

After much Googling, I have come across an answer for this here.

Basically it involves using the Robolectric unit testing framework, which intercepts the loading of the Android classes. You can then go ahead and use Mockito (although it isn't necessary in most cases) and run your tests on the JVM!

Answer 2

As of version 1.9.5 (released 3rd of June, 2012) you can use Mockito with Android. To do this you will also require dexmaker:

http://code.google.com/p/dexmaker/

This wiki page describes how to implement it:

http://code.google.com/p/dexmaker/wiki/Mockito

Answer 3

Take a look at android-mock. It's based on EasyMock 2.4 (so not quite as nice as Mockito but close).

It gets around the limitations of the DalvikVM by pre-generating the mock classes at build time rather than runtime, and then bunding them with your compiled test code when deploying to the device.

There's also a mocking framework called Borachio which I can't vouch for but looks promising (if you're happy to go through the motions of getting Scala to run on your device).

Answer 4

You can avoid it, for everything that has nothing to do with the Android SDK internal classes. That's what I'm doing for my Android projects (although I use JMock2, not Mockito).

I have two test projects.

• The first one uses JUnit4 and JMock2 that I added myself as dependencies. I test all the "business logic" classes, but I can't test anything that has to do with Android (UI classes, SQLiteOpenHelper, etc.) If I try to use them in my tests, I get the dreaded Stub! exception.

• The second one to test the UI, using ActivityInstrumentationTestCase2 and Robotium.

That may seem like a lot of work and complex, but really it's not, and I actually think it's better to separate them. UI tests are not "real" unit-tests and they often test some features across multiple units. If you properly separate your UI layer from your business logic (and doing this separation of tests will force you to do that, in TDD style), then it's all nice and smooth.