MVP is Model View Presenter
.. which is a pattern that is very popular among Android developers nowdays.
I don’t intend to write (yet) another guide about MVP in Android, because others have done a better job, for example:
- Antonio Leiva’s introduction to MVP
- Hannes Dorfmann’s introduction to Mosby
- Fernando Cejas’ post on clean architecture
A lot have been said about MVP (and other similar patterns), like:
- it isolates the business logic from the UI
- it makes faster and easier to unit test the business logic
- it avoids having a god Fragment or Activity class that manages everything
- it makes it easier to maintain the app
However, the first thing you notice while switching into “MVP mode”, is a great sense of order.
In all the (few) apps I wrote before, I ended up with the well known hodgepodgey fragment or activity that contained both the UI logic and the business logic.
By defining the responsabilities of the view and of the presenter with MVP, you implicitly define the interfaces between those two components (and the model), and everything fits its place.
Every touch, drag, and eventyally lifecycle events are just events that are reported back to the presenter, which then chooses what to do with them. This is powerful.
This post is about my experience with the MVP pattern, Dagger (2) and testing.
Given the definition of the interface between the view and the presenter, I ingenuosly expected that testing of both (using unit tests and Espresso tests) would have been super smooth. As it often happens, the reality is quite different from what one expects and reads from blogs. In this post I will try to sum up all the issues I had during that process and the solutions I tried to put in place.
In order to better illustrate the concepts, I wrote a little example that can be found on my github repo
The structure of the app is the same one the can be found googling for Dagger / MVP , for example here.
The only thing I added is a local component / module that I use in order to inject the stuff needed only by that particular set of classes.
This means that in addition to the global Component / Module classes, used to inject stuff like the storage, there will be a local Component / Module used, for example, to inject the presenter into the View.
The easy part: testing the presenter
The dependencies are resolved by passing what it needs as constructor parameters:
1 2 3 4 5 6
Since no injection magic is involved here, we can just mock the view and all the other stuff the presenter needs and easily write unit tests for a Presenter instance.
Moreover, all the dependencies with external models / sources of data like retrofit can be tested by testing the behaviour of the presenter.
The “I expected it to be easier part”: testing the view
A common approach I heard around is to test the view not against a mock presenter, but against a presenter injected with mocked “external components”, such as api client and storage.
What I wanted to achieve here on the other hand, is to test the view driving the behaviour of the presenter it interacts with.
With this strong separation of roles, I expected it to be easy to mock the presenter and test the view with Espresso.
Injecting a mock presenter
Since the presenter is provided by the local module and injected into the view by Dagger, I had to find a way to override the Module in order to provide the mock presenter that could drive the tests.
By using the common method to inject the view
1 2 3 4
the only way to override the presenter since it is provided by the “real” MainModule is to use build flavours, as shown in Android testing codelab.
However, I wanted to take advantage of Dagger 2 injecting a mock presenter.
The key of replacing a dependency is by overriding the Application object
By adding a factory method that returns an istance of the module in the Application class
1 2 3 4
Then we can be use a custom test runner that provides a subclass of that application object declared in the Manifest.
1 2 3 4 5 6 7
and declare it in our gradle file
1 2 3 4 5 6 7 8
The Application object (and its test variant) is the one responsible of providing all the modules, so by subclassing it we can drive what is provided to be injected:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
This is what the setup method would look like:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
A mock module is needed to provide a mock presenter. Then the mock module is passed to the application object. Please note that in order to have Dagger 2 working, the mock module needs to provide a view instance (even a mock one) that will never be used.
Now we can finally write a test method:
1 2 3 4 5 6
After all this struggling, we can “just test the view”, meaning that we do not need to test if the mocked rest end point was called, nor if the storage was asked to write something. We just test the view against the presenter interface
One piece is still missing: what if we want to test the behaviour of the view when one of its methods gets called by the presenter? In the example, the view interface offers a method to set the text displayed.
Again, one could naively think that it would be sufficient to call the method with something like
The truth is, espresso tests run in a thread different from the UI thread. By doing that, it would result in
Only the original thread that created a view hierarchy can touch its views
One way to overcome this, is to call the methods in the ui thread
1 2 3 4 5 6
Why I did not use the
Simply because it would have ended with another exception since startactivity cannot be called directly from the ui thread.
To sum up
- Make the application provide the Module that provides the presenter(s)
- Change the testrunner in order to provide a different application
- Let the “test” application provide a mock module that provides a mock presenter
The Mvp pattern isolates the view (which needs to be as dumb as it can) from the presenter. By instrumenting the view with a mocked presenter, you will drain those tests from any kind of logic we expect to be in the presenter. You just test that the interface between the presenter and the view is working as expected.
By doing this, you can focus on testing the business logic inside the presenter with vanilla unit tests. Your tdd loop will definetely be faster.
A big thank as always to my proofreaders Fabio Collini & Riccardo Ciovati!