Testing in Android (MVP) – Part 2

Integration Testing

Integration tests are important in Android so we can ensure the behavior of the integration between the view and the model work correctly. So how exactly do we write these integration tests since the presenter relies on 2 other objects the View & Model?

In the previous post, we added a new dependency to our project called MockK. What is MockK? Well, MockK is a mocking framework for Kotlin. A mocking framework allows us to verify the behavior of an object without having to build the objects from scratch among various other things.  More information about MockK can be found at the website.

So now we know about mocking frameworks let’s see how we use them to build out integration tests.

For brevity, I am only going to show how we use the mocking framework to write the integration tests although you can find the source code for the MainPresenter at the github page.


Alright, so what have we done here?

With the property fields, you will notice some annotations, @RelaxedMockK, @MockK. These annotations provide use with mocked version of the classes they sit above. For example, @RelaxedMockK on the Contract.View class is setting up a mock object that is relaxed in nature.

From the docs:

Relaxed mock is the mock that returns some simple value for all functions. This allows to skip specifying behavior for each case, while still allow to stub things you need. For reference types chained mocks are returned.


The @MockK annotation creates the standard version of the mocked object. This means we want to mock the class but will provide the behavior of the class when interacted with, however, we are passing it a parameter relaxUnitFun which tells the framework to allow functions returning Unit to be relaxed. In our case, this affects the setTipOption function which has no return value or Unit if you prefer to be explicit.

from the docs:

In case you would like Unit returning functions to be relaxed. You can use relaxUnitFun = true as an argument to mockk function, @MockKannotation or MockKAnntations.init function.


Although we only use these annotations, MockK provides many other useful annotations that are worth looking into.

The Setup

Okay, so now that we have understood a bit about the annotations we are using let’s turn our attention to the setup method:

Here we, initialize the mocks and set up the model to return the values we want to use when interacting with the mock. Additionally, we tell MockK to init the annotated classes from above. Since this method is annotated with @Before it will run before every test is executed.

The Tests

These two tests that we set up above allow us to ensure the behavior of the start method in our presenter as well as the changeTipPercent method. We then use the verify lambda from MockK to assure the view has been interacted with in an expected way. That’s it! You now know how to use MockK to write a simple integration test. What happens though when we want to adjust the behavior of a mock after setup occurs?

Changing behavior with every

Each of the above methods has a line:

This line is altering the behavior of the computeTotalPrice function of our model so we can verify the other methods of the view are interacted with in an expected way. We can now verify that the displayFinalPriceWithTip function of the view is called as well as the displayError method when we pass in a bad value.


Wow, look at you go! You now know how to create an integration test for your presenter in the MVP architecture using MockK. In the last part of this testing series with the MVP architecture we will take a look at the instrumentation tests on Android for running tests on an Emulator or physical device. See you then!

If you enjoyed this post please leave a comment, like or share, and follow me on social media.