Rocking Google’s Android App Unit Tests!

by TestFortExpert on 02/11/2015

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?

We Work With

Having one outside team deal with every aspect of quality assurance on your software project saves you time and money on creating an in-house QA department. We have dedicated testing engineers with years of experience, and here is what they can help you with.

Software is everywhere around us, and it’s essential for your testing team to be familiar with all the various types and platforms software can come with. In 21+ years, our QA team has tested every type of software there is, and here are some of their specialties.

There are dozens of different types of testing, but it takes a team of experts to know which ones are relevant to your software project and how to include them in the testing strategy the right way. These are just some of the testing types our QA engineers excel in.

The success of a software project depends, among other things, on whether it’s the right fit for the industry it’s in. And that is true not just for the development stage, but also for QA. Different industry have different software requirements, and our team knows all about them.

Full-Cycle Services

By Platform

By Type

Industries