Rocking Google’s Android App Unit Tests!


2 m read


Mobile Application Testing, Unit Testing

Top Difficulties

If there is a nice way of doing something it means such a way makes that particular something less difficult. What are the common issues popping up while your Android app unit testing session is running?

  • Android.jar! You have all downloaded Google’s Android SDK. Well, the Android.jar there is suspiciously like a well known C++ header file meaning no working code is found there. And all you are getting when you are trying to call a method all you get is a little message stating “Stub!”. Well, actual Android.jar implementations may be found in a device emulator. If your code is calling any of their methods it should be run on an emulator.
  • No main()! Activity or, well, the view (regarding app framework) is what starts an Android app. The starting activity is defined as well as launched from there. Considering view is the entry point all MVVP, MVC, and MVP pattern architecture is disrupted. What harm does this cause to unit testing? Architecture is built based on every Activity that, in turn, is a small app of its own while entry point is in the activity.
  • It’s not Java SE! It may feel that way when you are coding for your Android app, but it’s not. Surely Dalvik VM is a nice Java implementation but it’s not a Java VM. And it does not even use that Java byte code hence it runs on some cross-compiled .class files. So JMock or anything of that sort is not an option for mocking dependencies while unit tests are being written.

What choices do we have then?

We are facing a dilemma. JVM or device/emulator for running unit tests? Which one should we choose?Let’s consider both options:

  • Running unit tests on a PC with JVM
    • JVM is available within this approach and so is JMock as well as many other BDD frameworks, which is nice;
    • Tests are run faster hence they are run on a PC;
    • Running the code on various VMs decreases the risks of behavior being different in the real deal app;
    • No need to inherit from specialized Android classes hence standard unit testing practices are being used;
    • All the calls to real Android framework require being wrapped even if there is a need of calling Android classes or deep-in-app services.
  • Running unit tests on a device/emulator
    • Android framework APIs are available for testing, meaning objects may be called rather than mocked up;
    • If the real deal VM code is used we are true to real code execution;
    • Tests are slower hence are run on a device/emulator;
    • We are not able of using JMock and other BDD frameworks so we are left to using a relatively young Android mocking framework or rolling the mocks on our own.

Now, after considering all that data which path of mobile app testing is yours?

Realizing the importance of providing service on agreed terms, we consider all possible risks and provide efficient solutions for all possible risks and provide efficient solutions.


We use cookies to ensure your best experience. By continuing to browse this site, you accept the use of cookies and "third-party" cookies. For more information or to refuse consent to some cookies, please see our Privacy Policy and Cookie Policy