Presenter First

Approach

Presenter First concentrates on transforming each of a customer's requirements into a well tested, working feature as quickly and with as much correlation to the customer's story language (requirement) as possible. The language of the story or requirement is used to directly guide development of the feature – even naming the modules and function calls. As a consequence, the feature implementation tends to closely represent the customer's desire with little extraneous or unneeded functionality. The language of the source code also corresponds closely to the customer's stories.

Presenter First is often applied in graphical user interface applications. It is equally well applied to the development of command-line interfaces. Further, a slight variation of the approach has been used effectively in embedded software; here the integral design pattern is known as Model-Conductor-Hardware and the approach is termed Conductor First.

When used in GUI applications, this approach allows the presentation logic and business logic of the application to be developed in a test first manner decoupled from on-screen widgets. Thus, the vast majority of the application programming can be tested via unit tests in an automated test suite. In so doing, the reliance on GUI testing tools to perform extensive system testing can be reduced to verifying basic GUI operation or eliminated entirely.

Implementation

The MVP design pattern decouples on-screen widgets, presentation logic, and business logic. Presenter First starts the development process with the presenter component of an MVP axis. Test-driven development is accomplished by mocking the view and model and writing unit tests for the presenter. Production code for the presenter is then written and revised until the presenter unit tests pass. The cycle is repeated for the Model. Unit testing the View is usually impractical or impossible; thus, view code is left as "thin" and devoid of logic as possible (i.e. the View is a wrapper around widget library calls and presentation logic is contained in the presenter). The Presenter First approach applied to the MVP pattern allows the vast majority of application logic to be tested under automation leaving only simple on-screen verification testing of the View and its widgets.

The test cases for the presenter are determined from the customer requirements or stories. A customer will generally explain features in terms of 'when' statements – for example, "When I click the 'save' button then the file should be saved and the unsaved file warning should disappear." Unit tests and presenter code follow the flow of the 'when' statements. The presenter expects view events to be fired (e.g. the click of the save button), and in turn it will make calls on the view (e.g. hide the warning message) and the model (e.g. initiate file save operation) in response.

The many features of an application can make a single monolithic MVP axis unwieldy. Presenter First advocates breaking an application into multiple MVP axes. In a GUI application, each screen, dialog box, and complex widget is represented by an MVP axis (its functional design dictated by a customer story). Communication among the aggregated axis is accomplished through programmatic connections between models.