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? <
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!
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
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).
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.