Presenter First: TDD using MVP pattern for complex UIs
Presenter First (PF) is a combination of a process and a pattern; is an economical, effective technique for organizing source code and development activities to produce fully tested GUI applications from customer stories using test-driven development. The three elements of Presenter First are a strategy for how applications are developed and tested, a variant on the Model View Presenter (MVP) design pattern, and a particular means of composing MVP triads.
State of the art
Model:
The data and logic that serves the needs of a presenter for some aspect of the business.
View:
- The user interface of the application, user actions are forwarded to the presenter.
- To the customer, the view is the application. The view will therefore have a high rate of change throughout the project. Decoupling from this change is a major motivation for Presenter First.
- Handles the display of data and delegates all event processing to the presenter.
- Is very thin, with methods that consist of little more than firing properly typed events to be handled by the presenter. Presenter can then attach itself to these view events.
Presenter:
The presenter is the custom logic that allows the model to interact with the view, and vice versa (application wiring). It represents the functionality or flow within the MVP triad.
Although customer stories usually describe functionality in terms of doing something to the view and seeing results in the view, this should be managed in the presenter.
The presenter coordinates the UI with the data, ensuring they are in sync. Specifically, it updates the view and acts upon user events that are forwarded by the view. The presenter also retrieves data from the model, prepares it for display (by the view) and updates the model as necessary.
Presenter characteristics
- Is the center of the universe.
- Is the interpreter of events.
- Doesn’t work with any concrete classes.
- Is intentionally stateless, doesn’t have a public API.
Presenter First requires all communication to flow through the presenter so that the model and view are isolated from each other; this greatly improves the testability of each element of the MVP triad.
By starting with the presenter, and organizing development around it, the application may be built from user stories following test-driven development practices.
Unit testing the presenter gives us test coverage corresponding directly to user stories, it implicitly test the proper implementation of the “wiring” of the application. It isolates our code and tests from high rates of change in the view, moreover this changes are easy to make and present very low risk to the application.
Presenter First allows our application development to satisfy one of the most fundamental pillars of the agile approach: developing exactly what your customer wants, and nothing more. The portions of the code most prone to ambiguity and over-development (model and view) have specific and complete requirements based on customer stories. This substantially reduces over-engineering of code and wasted development time.
Benefits
The application’s functionality is coordinated between the view and the model by the presenter. This makes the presenter, and its suite of unit tests, a cohesive and centralized source of documentation for the application’s behavior.
Developers will spend less time focusing on the details of features (model and view) and more time on the functionality (presenter). The developer can work at a higher level of abstraction early in development versus getting distracted by details too early.
Functionality is easily testable using Presenter First. The interfaces of the model and view are easily mocked, thus putting the focus of the tests at the functionality level within the presenter class.
By mocking the model interface (for example with Mockito), the developer avoids problems such as connecting to a live database, having to use communication devices and manipulating files. The responsibility of testing those types of features is put on other classes within the actual model. Presenter First is only concerned with testing the functionality accessible through the user interface, not the details of how this functionality is actually implemented.
By examining the presenter class’s unit tests, developers can easily determine the behavior and rules of the user interface.
When large customers ask for a specific look and feel, as the view component implements the required view interface, changing what graphical user interface to use is painless. Different graphical user interfaces can easily be swapped in or out.
Presenter First is cost effective and practical for teams, separate teams can be creating code independently of each other at separate speeds and timelines.
Conclusion
Once mastered, Presenter First can be used to build a large GUI application in a way that is repeatable, maintainable, thoroughly tested, and user specified.
Suggestions
-Pass the model and view to the presenter via its constructor.
-A consequence of the shallow view is that the view interface takes only primitive types as parameters. Sending complex types to the view would require processing in the view, widening the view and requiring unit testing.
-The most common case is for the view to fire events that the presenter consumes, though model triggered events are also possible. Using events to communicate with the presenter allows for separate packaging of components, reduces compilation dependencies, and allows for the same view to be connected to presenters with different behaviors.
- View events could easily be mocked and fired in the presenter unit tests, simulating customer interaction.
Related Work
There is an interesting article that explains this topic very well , and another one that also introduces a library that helps to implement MVP on Android.
Example
We’ve developed a basic sample building a rough calculator app in order to get this concepts applied in an android project. It has two view (interfaces) concrete implementation with different components and UX; two concrete models that implement arithmetic roughly with different approach. You can clone the repo and get this approach rolling.
There is a lot of stuff about this broad topic, below is a list that summarizes the most interesting.
