Unit testing is an important part of any product development lifecycle. The main purpose of unit testing is to test components in isolation from each other and that is how our code should be written as well. To achieve this task of writing test cases for a class in isolation from the others, there are times when we need to mock some objects or data while writing our JUnit test cases. As the name Mockito suggests, it is a framework that allows us to do just that.
If the UI related part of our code is already tested by some testing framework like Espresso, then it need not be tested again. Also, we do not need to test code that relies on the Android OS. So, we can use Mockito to test our non-UI or functional code that is not dependent on the Android OS.
By default, when we run our local unit test cases, they run against a modified version of the android.jar file which does not contain any actual code because of which, when we try to invoke any method of an Android class from our test case, we get an exception. This is done to ensure that we test only our code and do not depend on some default behavior of the Android classes. We can also change this default behavior of throwing an exception to return zero or null values. However, we should avoid this as it could cause regressions in our test cases which are hard to debug. If we still wish to do this, it can be done by including the following in our project’s top-level build.gradle file:
We can substitute Android dependencies with mock objects. We can use Mockito for this to configure our mock objects to return some specific value when they are invoked.
To integrate Mockito in our Android apps, we first need to include the following dependencies in our app level build.gradle file.
Once we have added the required dependencies, we will create our test class in the directory module-name/src/test/java/, and add the @RunWith(MockitoJUnitRunner.class) annotation at the beginning of this class. This annotation tells the Mockito test runner to validate if the usage of the framework is correct and it also simplifies the mock object initializations.
We have to add @Mock annotation before the field declaration of any object we want to mock.
We can use the when() and thenReturn() methods to return a value when a particular condition is met in order to stub the behavior of any dependency.
Now, let’s have a look at a sample test class. The sample below checks that the method getHelloWorldString() of the class ClassUnderTest matches a given string.
How to Mock
We have 2 methods, mock() and spy() that can be used to create mock methods or fields.
Using the mock() method, we create complete mock or fake objects. The default behavior of mock methods is to do nothing.
Using the spy() method, we just spy or stub specific methods of a real object. As we use real objects in this case, if we do not stub the method, then the actual method is called.
We generally use mock() when we need complete mock objects, and use spy() when we need partial mock objects for which we need to mock or stub only certain methods.
Let’s see how we can use mock() and spy() methods:
In the above example, when we add an object to a mocked list, the object doesn’t actually gets added as the actual add method is not called. However, when we call add on a spied list, the object is actually added as the actual method is called.
Let’s look at how we can use Mockito methods to mock behaviour of the mock or spy objects we create.
It is used to configure simple return behavior for a mock or spy object.
It is used when we want to return a specific value when calling a method on a mock object. The mocked method is called in case of both mock and spy objects. doReturn() can also be used with methods that don’t return any value.
It is used when we want to return a specific value when calling a method on a mock object. The mocked method is called in case of mock objects, and real method in case of spy objects. thenReturn() always expects a return type.
To see a list of other available methods, you can refer to this link.
Now, let’s see how these method can be used for unit testing:
Now, let’s look at the common assertions we can use to assert that some condition is true:
A set of assertion methods.
assertEquals(Object expectedValue, Object actualValue) :
Asserts that two objects are equal.
assertTrue(boolean condition) :
Asserts that a condition is true.
assertFalse(boolean condition) :
Asserts that a condition is false.
To see a list of all available assertions, you can refer to this link.
With the combination of the above mentioned methods and assertions, we can write test cases using the Mockito mocking framework.
Advantages & Disadvantages
Let’s have a look at the advantages and disadvantages of Mockito:
- We can Mock any class or interface as per our need.
- It supports Test Spies, not just Mocks, thus it can be used for partial mocking as well.
- Mockito cannot test static classes. So, if you’re using Mockito, it’s recommended to change static classes to Singletons.
- Mockito cannot be used to test a private method.
There are a few alternative mocking libraries like PowerMock, Robolectric and EasyMock available as well which can be used.
This was all about how to write basic test cases using Mockito. I hope this blog encourages you to write unit test cases using Mockito or any similar framework. It might seem difficult at first, but once you get the hang of it, it will be of great use.
Hope you enjoyed reading.