Page Comparison

Software testing is important if we want to deliver good quality products. In Android, testing is not easy because the view (Activity or Fragment) is coupled with the model. The model refers to the business logic of the application. Separating the view from the model is essential if we want to make testing simple.

Type of Tests

According to android documentation there are two types of tests.

Local unit tests

Individual elements are tests and everything else is mocked including the Android framework dependencies. An element is the smallest testable unit of the application. These tests are good for validating the business logic.

Instrumentation tests

Individual elements are combined and tests together as a group. The tests run on an android device or emulator. The emphasis here is to test user stories and to mimic user interactions in the app.

Local Unit Tests

In order to make unit testing simple, we have to consider separating the view from the model. To do this, let's consider the common design patterns that we have in Android.

Model View Controller (MVP)

Model is the underlying business logic, the view interacts with the user and the controller exposes the model to the outside world.It's important to note that the model is not the domain model (a java objects used to save and retrieve data from the database).

Image Added

From illustration above the view is not dumb because it can also communicate with the model. The lack of clear separation of concerns between the view and the model makes this design unsuitable for unit testing.

Model View Presenter (MVP)

This is similar to MVC above except that the presenter replaces the model. The presenter acts as a mediator between the model and the view. This means that the two components cannot directly communicate with each other. The view is dumb because it just recieves and sends instructions to the presenter.

Image Added

The clear separation of concerns between the view and the model makes this design pattern ideal for testing. Unit tests for the two component can be easily created by mocking the view.

Although MVP pattern is simple and easy to implement, there are various ways to do this. We have discussed this and came up with our customized versions of MVP as OpenSRP developers.

OpenSRP MVP Rules

Create a contract (Java interace) that has interfaces for the view, model and presenter.
The three components should implement interfaces from the contract created in 1 above
In each component, reference the interface of the other component rather than the implementation.
Model should be referenced in the Presenter and not the View
View should not be referenced in the Model
Avoid android dependencies in the Presenter
Use an interactor to calls to the database or network layer i.e. using Async Tasks or Handlers
Interactor should sit between the Presenter and the model
Interactor should be initialized in the Presenter
Have one contract for each concept that defines the interfaces for the view, presenter and model
Start async tasks in the interactor
All database calls should be made using: