Android: Unit testing Android applications with Robolectric and Mockito

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?

  • When to use IntentSender vs. PendingIntent?
  • Android RSA Keypair Generation - Should I use Standard Java/Bouncy Castle/Spongy Castle/JSch/Other?
  • How to draw and scale a bitmap on a canvas using bicubic interpolation in Android?
  • How to get listview height in android?
  • Fragment activity crashes on screen rotate
  • last block incomplete with CipherInputStream/CipherOutputStream, even with padding AES/CBC/PKCS5Padding
  • Mockito doesn’t play nice on the Dalvik VM, see this post: Using Mockito with Android virtual machine


    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.

    Related posts:

    DatePicker.OnDateChangedListener called twice
    Android New Intent start particular method
    ViewPager and OnItemClickListener in ListView
    Alarm Manager Example
    How to grant MODIFY_PHONE_STATE permission for apps ran on Gingerbread
    Android Spinner selection
  • Unit Testing MVP using mockito with event listeners
  • LinearLayout.LayoutParams how to use dip…?
  • Getting GCM Registration ID using Firebase
  • How to store modulus, public exponent and private exponent securely on Android?
  • Android facebook applicationId cannot be null
  • Android LVL Signature Verification Failed
  • 4 Solutions collect form web for “Android: Unit testing Android applications with Robolectric and Mockito”

    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:

    This wiki page describes how to implement it:

    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.

    Android Babe is a Google Android Fan, All about Android Phones, Android Wear, Android Dev and Android Games Apps and so on.