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 inImplementation
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.References
* *{{cite journal , last1=Crosby, first1=David, last2=Erickson, first2=Carl , issue=February, 2007 , title=Big, Complex, and Tested? Just Say 'When' , url=http://atomicobject.com/files/BigComplexTested_Feb07.pdf , journal=Better Software Magazine , archive-url=https://web.archive.org/web/20110701083800/https://atomicobject.com/files/BigComplexTested_Feb07.pdf , archive-date=2011-07-01External links