In order to deliver good quality products, we need to embrace Software Testing. This helps us identify bugs swiftly and verify that our software is fit for use.
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. In Android, testing these units is not easy because the view (Activity or Fragment) is coupled with the model (business logic of the application) . Separating the view from the model is essential if we want to make testing simple.
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).
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.
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) for each concept and define interfaces for the view, model and presenter in the contract.
- The three components should implement interfaces from the contract created in rule 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 make 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.
- All database calls should be made using:
- Async tasks
- Future tasks (We need a way of moving this from the main thread).
- Prester tests should mock the view and the interactor (If implemented).
- Model tests should mock the presenter.
We have created sample mvp applications that respect these rules in https://github.com/OpenSRP/opensrp-client-architecture/tree/mvp
Please check them out and if possible add your sample mvp application there.
Instrumentation Tests
References
https://developer.android.com/studio/test/
http://softwaretestingfundamentals.com/unit-testing/
https://en.wikipedia.org/wiki/Software_testing#Unit_testing
http://softwaretestingfundamentals.com/integration-testing
https://code.tutsplus.com/tutorials/an-introduction-to-model-view-presenter-on-android--cms-26162
https://code.tutsplus.com/tutorials/how-to-adopt-model-view-presenter-on-android--cms-26206
https://android.jlelse.eu/android-mvp-for-beginners-25889c500443