main banner

Mobile Development

Unit testing in Android

Unit tests are a very important practice in software development, and a very misunderstood one. It’s one of those things that you know is the right thing to do, but you never do it anyway; like cleaning that room on your house full of things that are never used, but you keep around “just in case” (Who collects tons of boxes just in case you need to move to another house?).

Perhaps it’s the feeling that unit tests are a daunting task with little rewards what keeps them from getting implemented from project to project. In a way it’s true, unit tests are a daunting task when you don’t know how to use them. Their most visible value usually arises in maintenance, after the product has already been released and you don’t want to touch it because of the fear of breaking something that already works. And it’s a shame that very few projects think about future maintenance when they get started.

But unit tests not only have the benefit of an automatic full regression test of the product every time you want; they help you design your product from the very beginning, because testable code is modular code and modular code is smaller and easier to understand. In order to successfully implement unit tests in any given project you need 3 things:

 

1.-Testable code.

2.-Kowledge about how to implement unit tests.

3.-Time.

 

Unfortunately, Android is not particularly unit-test friendly, which makes it even harder to implement unit tests on this platform. Although the official tools and documentation have examples of implementing tests of different kinds, their “unit tests” have the very big disadvantage that they need to be run on a device or emulator, which is impractical and super slow.

Fortunately, there’s still people who thinks that unit tests must be run on the developer machine, and that they must be capable of using existing, powerful and standard tools for testing that are already broadly adopted and considered industry-standard. The most famous is project Robolectric (http://robolectric.org/), which is an enormous effort since it needs to rewrite or implement the Android SDK in order to allow code execution outside Dalvik. However, the Android tools change so frequently in non-backwards compatible ways, that efforts to implement true unit tests are constantly threatened and need to be adjusted. In this post I’m going to share a method for integrating robolectric unit tests in an Android project that uses Gradle and Android Studio.


Project structure

testing

The idea is simple: Since the Android Gradle plugin apparently refuses to work nicely with any other plugin, configuration or build customization from the Gradle world; you create another module in the project in which the unit tests will live (make sure to add it to settings.gradle). This new module is a standard java module that follows the known conventions inherited from the maven world, where test classes are stored under src/test/java.


Unit tests build.gradle

code

In this file you must declare a dependency on the app module, but also on its classpath. Take into account that robolectric 2.3 has a dependency to android -support-v4, so you need to include the Android repository in order to resolve dependencies. This is accomplished by reading the environment variable ANDROID_HOME. In the dependencies section you can use the latest version of junit and mocking frameworks like Mockito!


Sample test class

code

The above is a simple example of a test for an echo application, in which you enter some text into an EditText, press a button and then see the entered text on a TextView on the screen. The tests can be run from the command line in the root of the project: gradlew/gradlew.bat test

I hope you find this example useful, remember that the Android team is constantly changing the android-gradle plugin in non backward compatible ways, so maybe the build.gradle file would need some adjustments to correctly reference the classpath of the android module. Happy coding!

 

German M.

German has many years of experience working as a developer and his experience is very valuable!

Articles