Using Espresso and Mockito to test a MVP app

Olivier Goutay
AndroidPub
Published in
3 min readMay 1, 2017

I have seen a lot of interesting posts on how to do a clean MVP pattern, if you are interested to learn how it works, don’t hesitate to check these other posts:

What I wanted to describe here is how to use Espresso and Mockito together with the MVP pattern to write super fast Instrumentation tests for the Presenter. I’m not gonna talk about testing the Models or the Views, since it’s pretty similar to other patterns.

What to test in your Presenter?

To summarize, the Presenter holds the logic between your View and your Model. You probably want to test three things in your tests:

  • The contract between Presenter and View
  • The contract between Presenter and Model
  • The logic in your Presenter

Actually, you want to test almost everything haha, since the Presenter is gonna have the whole responsibility of showing data to the user.

Note: I called “contract” the interface between View<->Presenter<->Model. I liked that way of doing MVP, since the interfaces are all defined in the same place, in that Contract class.

How to “unit” test your Presenter?

Mockito is gonna help you doing that. By mocking the Model and the View in your Presenter, it’s easy to test their relationship and have a good code coverage.

How to mock the view?

MainActivityPresenter mainActivityPresenter = new MainActivityPresenter();
MainActivityContract.MainActivityView mainActivityView = mock(MainActivityContract.MainActivityView.class);
mainActivityPresenter.attach(mainActivityView);

Explanations:
You create your Presenter first, then mock an instance of MainActivityView and finally you attach your View to the Presenter. In the end, you can verify that MainActivityView is called with the right params.

How to mock the Model?

MovieSearchService movieSearchService = mock(MovieSearchService.class);
HttpManager.getInstance().setMovieSearchService(movieSearchService);
when(movieSearchService.getMovies(anyString(), anyString(), anyInt())).thenReturn(Observable.just(searchResults));

Explanations:
You create a mock of the Http service first, then you set that mocked service into your HttpManager and finally you can mock Http responses from that mock. You can also verify that the right methods are called with the right params.

Note:
Check the github example below, MainActivityPresenterTest for a code example.

Performances?

As you can see, the Presenter test is ~10–20 times faster than an old school Instrumentation test on the MainActivity. It’s pretty nice!

I would be lying to you though if I was saying that what is tested here is the same thing. In the MainActivityTest, we actually partially test the Model, since we don’t use Mockito and we do a real http request. In the Presenter test, we mock this response and thus are not testing the http part of the Model.

Even by testing the Model separately, I found out that you still can achieve ~5–10 times faster test by using the MVP pattern for testing. It’s simply that your Model test is gonna run only once, and you have also a better control over the coverage. So overall, it’s still a win-win situation with MVP :)

Going further and Github example

Usually I also like to test the Models, since it’s containing the logic between your server and your app. It’s not demonstrated in this example but don’t hesitate to contact me if you have questions about that.

Usually in the MVP pattern, I find useless to test the View part, since it’s supposed to do only simple actions (setText, showToast etc…). That said, it depends also on your level of confidence and the time you have :)

Don’t hesitate to check out the example app at:
https://github.com/omadahealth/AndroidMVPDemo

--

--

Olivier Goutay
AndroidPub

Senior Software Engineer @ Solana Labs | Ex-Netflix | Ex-Mentor at Code2040