My Hexaville
Spead the Word
android tests with mockito

Android Testing pt. 1.2 | Local Unit Tests With Mockito

This is the second part of the tutorial about Android local unit tests. Today we’ll learn some Mockito and what we can do with it

Purpose of Mockito

So if you’re not much into testing – you might’ve just heard about this library or even not. Mockito helps you to abstract from other modules/classes and still focus on one class in your unit tests. Even if it depends on other classes

So what do I mean by that? Let’s say we have a slightly more complex class that we want to test than in the previous post. That class has many dependencies, which means that if we want to test it – it’s not going to be a unit test anymore. Again, unit – means one class/method, not  a whole package or module test

So with Mockito you can ignore those dependencies and focus on just one class/method that you’re testing. And if you actually need mocked classes to return something – you can implement it as well

Design First

So I went through this awesome tutorial, which covers unit tests not so much, but there’s a GitHub repo, which has everything that’s not in the tutorial

And the first thing they covered was MVP (Model View Presenter) architecture design. Now I’ve heard it many times, but never really understood was it’s all about and why should I care. The way I’m writing code is XML layouts with Data Binding for some small display logic and activities/ fragments for the rest, like networking, user interactions etc

Now, why I’m taking the time to talk about MVP is because, without it, it seems way harder to write unit tests for your app. Remember, Google recommends to write 70% of unit tests? This means unit tests should cover your fragments/activities and more

And usually with the way I currently write code, setting up my fragments for unit testing would take me lots of time or even would be nearly impossible. Because it’s like one atomic entity

This is definitely a huge topic and it needs many examples, so I’ll make a tutorial in the future

What you need to understand is that View has access to your layout, views. It will take care of updating layout, it has public methods, declaring what basically it can do

Model is your API for backend/database or any way to retrieve some data to display

And Presenter is your user interactions, all the main logic. It sits on top of everything and talks to model/view.

android tests with mockito


Mockito setup

Add this Gradle dependency


So here’s the example I wanna show you, it’s going to be a chat activity with user input at the bottom. Just as one side only conversation, to add messages to the list. First, we create a contract interface, because it helps to think at a higher abstraction first.

So the send button will go grey/disabled when an input is empty. In the regular approach, I would just write everything in activity. But this is MVP and you might think of it as an overhead, but it helps in testing, makes you think of architecture design and I believe will make your code cleaner in the end.

I applied a passive view architecture solution which means that View shouldn’t have any logic at all. It just updates UI, delegates all user interactions to Presenter. Meaning that for EditTextView’s text change listener we delegate logic to Presenter, then it checks if string is empty – tell a view to disable send button, otherwise enable it

Let’s add some stub classes. In this post, we’re just testing a Presenter and since MVP is so modular, we don’t even need to implement anything from activity/layouts to test our Presenter

Unit Tests

And we can start implementing our tests already. Remember, tests come first

You annotate objects with @Mock and then call MockitoAnnotations.initMocks(). Now we can just pass this object and call its methods. Without Mockito it would through a NullPointerException.

This way we make sure that our ChatPresenter does call View’s methods that it suppose to, keeping tests very narrow


And here’s ChatPresenter implementation that passes all tests


android tests with mockito


What we did is we built a some kind of framework using MVP architecture and tested part of it, without testing any UI state/changes. We just tested that our user interactions call correct methods, wihout even knowing what they do/testing them. And withouy any api of a model to keep it focused on tests.

This is not a complete overview of Mockito, but more like a sneak peak. I’m sticking with testing topic for a while, so stay tuned for more cool stuff. If you want to learn about MVP – check this great post

We’ll see what we can do with Robolectric in the future post


About the Author Ihor Klimov

Formerly an Android developer, lately picked up some Flutter. This blog is everything that I find exciting about Android and Flutter development. Stay tuned and hope to see you again!