Unit testing with Android


A well thought-out test strategy (and supporting tools) is an essential part to delivering high quality products to customers.

Unit tests are the bread and butter for most application development, and Android apps are no different. Many people ask “why do we even need unit tests ?” The main reason is to build confidence that our applications are working as built/designed. Furthermore (and maybe more importantly) to ensure we are not detrimentally affecting the app while we are working on it.

There are several frameworks and libraries that we can choose from when implementing unit tests in Android. Each of them have different advantages and disadvantages. In this article I am going to describe the pros and cons I have found while using the currently available libraries.

Framework

Like any part of our codebase, our unit tests can get confusing and messy if not organized and properly maintained. Using a well-established framework and patterns that these offer, can do a lot to ensure that our tests are not only readable, but also easy to maintain and practically useful.

JUnit4

JUnit is unit testing framework not only for Android, but also for java in general. It is simple and has always been part of the java or Android IDE.

advantages

  • You do not need to import plugins to run JUnit for most of IDEs.

  • Very light library which means faster to initiate the unit test.

disadvantages

  • Less powerful then other framework in terms of assertion.

  • When unit test is growing then it is very easily get unstructured.

Example the simplest form of JUnit :

Spekk

Spekk and kotlin are a match made in heaven. Spekk is the cool, new hispter kid on the block. If you are familiar with rspec for ruby on rails, then Spekk would somehow be its sibling. You can check complete specification of Spekk on spekframework.org

advantages

  • It is easier to read compared to other frameworks.

  • has grouping function which make easier to isolate context.

disadvantages

  • Not all IDE support spekk.

  • you need the right plugin to run single test.

Example the simplest form of Spekk:

Mocking ( stubbing )

I know some of you are taking out knives and would like to “stub” me (pardon the pun). If you have megaphone then you might point it to my ear and yell “Mocking and Stubbing are two different thing!”. Yes, you are right! However, I put the title mocking here to make it easier for beginners to understand. What you saw by Mock in Android unit test library below is actually stubbing.

Mockito

Mockito is a simple, but strong library to stub methods and simplify unit test. It was very limited in the past, but the latest version is able to stub final classes and methods. It is using annotation to simplify the implementation.

advantages

  • Simple and easy to understand no magic involved.

  • Thread safe.

disadvantages

  • Limited on stub functionality.

  • cannot be used to stubbing constructor.

example the simplest form of stubbing with mockito:

Robolectric

Before there was the strong Mockito we needed Robolectric. However, we might still need this library to stub Android native library without instrumentation test.

advantages

  • It is particularly good at stubbing of constructor.

  • can be used for both unit and instrumentation test.

disadvantages

  • setup could be painful.

  • big library means slow initiation on running unit test.

example the simplest form of stubbing with Robolectric:


Mockk

Mockk is a stubbing library made specifically for Kotlin and it’s awesome. It simplifies a lot of syntax compared to Mockito. Check this link for complete documentation : mockk.io

advantages

  • like mockito but easier to read and more powerful.

  • it has relaxed function for lazy stubbing.

disadvantages

  • cannot stub constructor.

  • cannot stub private method.

example the simplest form of stubbing with mockk:




Alright that’s all I have for now. We will dig deeper into the best option from my perspective on the next one. If you are looking unit test on nodejs then you might want to check this awesome blog on jest

The views expressed on this blog post are mine alone and do not necessarily reflect the views of my employer, Optus Administration Pty Ltd.

Previous
Previous

From Quality Assurance to Quality Assistance

Next
Next

How we brought in-app messages to our app | Part 1: Segment (CDP), a Lambda and a DynamoDB