Lendo o artigo Big Complex, and tested? Just say “When” me animei a escrever código em Smalltalk para exercitar as idéias relativas ao método Presenter First e organização do código no estilo Model, View, Presenter. Iniciei um projeto simples para evitar me meter com complicações da interface gráfica com Morphs. A idéia é exibir um quadrado (um Morph) que vá mostrando as cores na sequência de cores red, green, blue, conforme se clica com o botão esquerdo do mouse (red button no jargão dos smalltalkers).

Começando com o Presenter primeiro

O presenter mantém referências para model e view.

A classe RGBSquarePresenter conterá apenas a inicialização conforme abaixo:

O código acima expressa a user story até agora (quando o botão esquerdo for pressionado mudar a cor na interface do usuário para a próxima cor na sequência red green blue) , no estilo idiomático “say when”, decomposta em dois eventos:

• Quando o botão esquerdo for pressionado mudar a cor no modelo para a próxima cor na sequência red green blue;
• Quando a cor no modelo for alterada atualizar a cor na interface do usuário.

Nota: Os eventos nas user stories devem ser denominados com nomes de alto nível. No código na interface do usuário será feita a tradução dos eventos de baixo nível para os de alto nível: #redButtonPressed para #nextColor, como veremos adiante.

Podemos extrair os eventos e as interfaces necessários para a view e o model inspecionando initializeEvents.

Criando os testes do model primeiro

Dentro da filosofia test first vamos criar os testes para a classe do model:

Escrevendo o model para passar nos testes

O model para passar nos testes é o seguinte:

Nota: Omitiremos os accessors enquanto forem triviais.

Criando um trait para o idioma “say when”

Agora vamos instalar o sistema de eventos do idioma when: do:. Como na construção da interface do usuário usaremos herança da classe Morph não vamos poder usar o mesmo mecanismo para herdar os métodos necessários para os eventos. Usaremos então traits. Vamos definir o seguinte trait:

Nota: O método revisit, que serve para colocação de comentários que podem ser revistados posteriormente, é baseado em Leaving Notes In Your Code do tutorial A Development Example for Squeak 3.9. Para descobrir onde foram colocadas chamadas para o método revisit basta usar a ferramenta Messages Names e obter os senders de revisit.

Nota: Para conhecer a tese sobre traits leia Traits — Composing Classes from Behavioral Building Blocks.

Usando o trait no model

Vamos incluir o trait criado no model (veja a segunda linha):

Agora é necessário fazer override do glue method events, que é requerido:

Nota: O model, com o uso do trait, também está livre para usar herança em qualquer ponto da hierarquia de classes.

Encerramos a parte 1 aqui. Na parte 2 vamos tratar da interface gráfica do usuário.

Presenter First (PF) is a technique for organizing source code and development activities to produce fully tested GUI applications from customer stories using test-driven development.

As we all know, interfaces be them for desktop applications or for web applications are hard to get right and usually get bogged down with validation and business code that we know shouldn’t be there but it is so convenient that we always end up succumbing to the temptation. This eventually escalates and we end up with very long test plans because there isn’t any sane way of unit testing the code that is behind the web pages or windows forms.

The point of Presenter First is to move as much code as possible out of the UI and into classes that can be unit tested.

Here is an annotated bibliography:

The Humble Dialog Box by Michael Feathers

Start here! This short article/tutorial inspired the creators of Presenter First and it puts you in the right mindset for understanding the concepts presented later.

http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

Presenter First: Organizing Complex GUI Applications for Test-Driven Development

This is the seminal article with an in-depth explanation of the process using Ruby. Note that this is all language agnostic and applies to C#, Perl, VB, etc.

http://atomicobject.com/files/PresenterFirstAgile2006.pdf

Brian Marick’s Presenter First wireframe demo (quicktime movie)

Interesting screencast and take on the method. Very easy to follow but you need to install Quicktime.

http://www.testing.com/cgi-bin/blog/2007/01/05#wireframe2

Three part video interview with the guys from Atomic Object

Ron Jacobs from http://www.arcast.tv/ interviews Atomic Object’s developers in a very long but very interesting discussion about systems architecture and Presenter First.

http://channel9.msdn.com/ShowPost.aspx?PostID=312305

Home page of Presenter First

More links and sample code. Especially the primer in c#: http://atomicobject.com/files/Puzzle.zip

http://atomicobject.com/pages/Presenter+First

http://en.wikipedia.org/wiki/Presenter_First

Other MVP articles

Model View Presenter using Dependency Injection and Threading support
http://www.codeproject.com/KB/cs/ModelViewPresenterWithDI.aspx

A series of articles about MVP in Codeproject
http://www.codeproject.com/KB/architecture/DotNetMVPFramework_Part1.aspx

A complete series on how to apply this family of patterns to UI design using Winforms. Recommended.
The link is very long so click here

Final Words

This article should have appeared before the series that I am developing about Presenter First but somehow got left for later. The series contains so far two articles:

http://codefornothing.wordpress.com/2007/09/15/model-view-presenter-in-visual-basic-6-part-1/
http://codefornothing.wordpress.com/2007/10/15/model-view-presenter-in-visual-basic-6-part-2/

There are more to come soon. I intend to finish the VB6 saga with a third part and then start a new series about Presenter First and .NET.

The idea is to take the steps presented in atomic object’s PresenterFirstAgile2006 paper and customise them into a tight dev loop, and a large project (including client interaction loop) around my own work style.

So initially I start with:

1. Create a stub presenter class that takes a model interface and a view interface via its constructor (constructor dependency injection)
2. Create mock test objects that satisfy the model and view interfaces
3. For all user stories in customer priority order
   1. Analyse story for impact on view
   2. Add support to view interface for the story
   3. Analyse story for impact on model
   4. Add support to model interface for the story
   5. Implement methods in the mock objects for new methods confirming they were called or returning typical data
   6. Do everything that can possibly break for this story (everything you can think of)
   7. Write a test for the presenter that exercises the application via an event or action on the view or model (an external system event)
   8. Make assertions on the state of the model and the state of the view
   9. Implement private methods in the presenter
   10. Until all tests pass
   11. Create a minimal user interface implementation to satisfy the view interface for this story

Stories

So it’s assumed that you’ve already got some User Stories (a presentation)… Given the scale of this demo, I’m going perform a massive overkill on the detail of the stories, however I need to include them as they form an important part of my loop so far.

So my stories are just including an id, title, text, priority (high~5 low~1), estimate (in hours, supposed to be days but, what the hell). Plus the option to write on the back of the ‘card’ extra notes regarding client discussion or ideas for tests.