If you have not been writing a lot of tests for your Android projects, you might fit it difficult to start. You really want to write tests for your Android projects, but you find it really difficult to do. There are multiple factors that contribute to this, but one of the biggest factors is the architecture model you are using.
Architectures for Android
When you create a new Android project with Android Studio, the starter template projects even an empty activity encourage you to put all the code in the activity. As a result, you end up with activities containing both the business logic and user interface (UI) logic. Under this type of architecture, you end up with an MVC (Model View Controller) model. The issue is that since the UI and business logic are stuck together it becomes difficult to write tests that would test the UI and business logic separately.
There are multiple architecture patterns that you can adapt to make your Android code more testable. Some popular choices are Model View Presenter (MVP) and Model View View Model (MVVM). I am going to focus strictly on MVP for this post.
Differences Between MVC and MVP
Since MVC is probably the model that most Android developers will be more familiar with, I believe it is important to see how it is different from MVP.
In an MVC model, the view can communicate directly with the model. The controllers are also behavior based and can share multiple views.
In an MVP model, there is usually a one-to-one mapping between a View and Presenter. The View is separated from the Model. The Presenter acts as a communication channel to the Model for the View.
Model View Presenter Architecture for Android
The MVP architecture pattern consists of three parts: View, Presenter, and Model. It separates the data model (business logic) from a view through a presenter. This separation of business logic and UI logic increases the testability of your code. The reason why that is the case is that now you can write tests for only the business logic and separate tests for only the UI logic.
Each of the components of the MVP model has a specific role. It will vary a bit depending on your implementation, but for the most part, they will fall under the following.
View
A view contains the visual part of the application. It contains only the UI and does not contain any logic or knowledge of the data displayed. Usually, implementations of the view components export an interface that is used by the presenter. The presenter can use the interface methods to manipulate the view.
Presenter
The presenter acts as the middleman between the view and the model. It triggers the business logic and tells the view when to update. So, the presenter will usually interact with the model and fetches and transforms data from the model to update the view. It is important to note that the presenter should not have any dependency to the Android SDK.
Model
The model contains the business logic. It holds a data provider and the code to fetch and update data. This is where you would update the database or fetch data from a web server.
Considerations When Using Model View Presenter Design Pattern
When you are aiming to have your Android project be testable, MVP is definitely a great choice. However, there are some disadvantages associated with MVP. One thing to consider is that you’ll need to write more code. Another thing is that not every Android developer will find the code structure easy to understand.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What are your experiences with testing Android applications?
To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.
Pingback: Testing and Android - Part 1: Overview - bright developers
Pingback: Testing and Android - Part 4: Model View Presenter Unit and UI Testing - bright developers