Unit testing with Android
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.