Testing Android MVP

Posted on Sep 5, 2016

There are thousands of articles explaining the good, bad and ugly of different programming patterns for Android, sadly most of the articles found online forget to explain one last important step: Testing.

Choosing between one pattern or another is both a matter of personal preference and project requirements. I don’t believe MVP is superior to MVVM or a full custom solution, however its simplicity is the reason it is my pattern to-go when creating a new screen.

MVP in four bullet points

Testing principles for MVP

Testing the Model

Testing the Model is something we should be doing independently if we are doing MVP or no. In some cases, our Model will be a 3rd party library we can’t test, so we should be able to provide an easy to mock interface.


Let’s follow an example for the full article. The Model is class that provides the user profile as an Observable (we don’t know if it comes from a local database or from the Internet), and it is defined with an Interface.

I would test this by using the TestSubscriber from RxJava and making sure that I get the expected value with no errors.

Testing the View

Testing the View is easier than we think, the most complex part is the Robolectric setup, but after doing it once, doing the same for all views will be easy.

Like any other MVP implementation, here we have the View Interface:

Our example View will be a custom Android View that extends FrameLayout

What should we test here? EVERYTHING!

And here is the test class:

Step by Step:

We have covered all lines of code from our View, and it really doesn’t get more complicated than this once you start adding more and more logic and UI elements.

In summary:

Testing the Presenter

We will test the Presenter the same way we tested the Model, with a simple JUnit test. However this time we will provide a mocked View to verify that the Presenter is communicating correctly with the View.

Our Presenter will receive a View and obtain the data from the Model to display it on the View.

The example ProfilePresenter provided is not handling a lot of the RxJava Gotchas you should take care of, because for the brevity of this article they have been removed.

What we want to test here is that the Model (ProfileInteractor) and the View receive the correct calls from the Presenter. We are actually not interested in verifying the data, but if your Presenter was doing some data transformation you should test that as well.

You should test also how the Presenter will handle errors from the Model. With RxJava you can do that by returning an Observable.error(new Throwable()) from the getUserProfile().

Step by step:

In summary:

Key Concepts

I hope that next time you are writing an App and using the MVP programming pattern, you will do it with these concepts in mind so you will create fast unit tests.

Share Tweet