O documento discute a implementação de uma funcionalidade de "gostar ou não gostar" em um site de namoro utilizando técnicas de BDD e API first. O autor descreve como modelou as camadas, APIs e casos de uso da funcionalidade através de testes executáveis para garantir uma arquitetura de qualidade e maleável.

1. © 2015 Marcio Marchini
BDD Minimalista no
NamoroOn.com :
um Exemplo Pragmático de
API First
Marcio Marchini
www.BetterDeveloper.net
2015/11/02

2. © 2015 Marcio Marchini
O Poblema: Ajudando em www.NamoroOn.com
Implementar o “Gosta ou
Não?” (tipo Tinder)
Servidor existente
(“legado” sem BDD/TDD)

3. © 2015 Marcio Marchini
Passo 1: API First
Preciso de camadas (MVC)
Preciso de APIs
API First (Jim des Rivieres)
Insight: Um teste é uma
spec executável de uma
use case da API (mindset
diferente!)

4. © 2015 Marcio Marchini
Passo 2: Pensando na camada Modelo
Tenho que ter a nova
funcionalidade na camada
Modelo
Tenho que poder usar de uma
GUI ou até mesmo de uma UI de
texto se for o caso
Insight: Testes podem ser
vistos como uma “UI de texto”

5. © 2015 Marcio Marchini
Passo 3: Modelando camada Modelo
Rankeamento de pessoas
Engine independente de GUI
(Camadas!)
 Descoberta a abstração:
“RankingEngine” (nome da
classe com a fachada da API –
service API)

6. © 2015 Marcio Marchini
Passo 4: Modelando a API
Idealmente como User Stories
Idealmente polimórficas (multi
camada se possível)
Idealmente de validação
executável

7. © 2015 Marcio Marchini
Passo 4: Modelando as Use Cases da API
1. Rankeados como Gostados São
Listados como Gostados
2. Rankeados como Não Gostados São
Listados como Não Gostados
3. Deve Ser Possível Rankear um
grupo de uma só vez (perf)
4. Deve Ser Possível obter quem me
Gostou tambem(Nos Gostamos)
5. ...

8. © 2015 Marcio Marchini
Passo 4: Modelando as Use Cases da API
5. Voto Duplicado Deve Ser Ignorado
6. Deve ser possível ser notificado
quando alguém gosta
unilateralmente de mim (Observer
Pattern!!!)
7. Deve ser possível ser notificado
quando alguém gosta mutuamente
de mim (Observer Pattern!!!)

9. © 2015 Marcio Marchini
Passo 5: Modelando as Use Cases da API com Testes
Por pragmatismo: usar framework
de teste unitário
Cada teste instancia a engine
Note: Pensar em serviços não quer dizer se prender a REST!!!

10. © 2015 Marcio Marchini
Passo 5: Modelando as Use Cases da API com Testes
Cada teste exercita uma ou mais
das APIs para completar toda
uma Use Case da API:
rank_as_liked ... ranked_as_liked?

11. © 2015 Marcio Marchini
Passo 5: Modelando as Use Cases da API com Testes
Vários testes da API (use cases):

12. © 2015 Marcio Marchini
Parênteses: Note o padrão nos nomes
1. Canônico:
As a <role> I should be able to <action>
in order to <value>
2. Pro Infinitivo:
<role> can <action>…
3. Nome do teste/spec:
test_[role]_can_<action>
4. Alternativa: Deve ser possível…
test_it_is_possible_to_<action>

13. © 2015 Marcio Marchini
Passo 6: Implementando a Camada Modelo
A API da Engine:

14. © 2015 Marcio Marchini
Passo 7: Rodar Testes, Verificar Cobertura etc
Rodar da IDE
Rodar do cmd-line, etc. Varia de
IDE pra IDE, de runtime pra
runtime, de linguagem pra
linguagem (uso Paver)

15. © 2015 Marcio Marchini
Passo 8: Repetir a dose pra camada Controller - testes
Mesma coisa na camada
Controller
Tentar preservar mesmas use
cases e mesma APIs, se possível
(API polimórfica de camada)

16. © 2015 Marcio Marchini
Passo 8: Modelando as Use Cases da API [REST] com Testes
Cada teste exercita uma ou mais
das APIs para completar toda a
Use Case da API:
(.../rank/group, .../rank/liked)

17. © 2015 Marcio Marchini
Passo 8: Repetir a dose pra camada Controller - impl
Mesma coisa na camada
Controller
Tentar preservar mesmas APIs, se
possível (API polimórfica de
camada)
Parâmetros e APIs extra são o
valor agregado da camada (auth)

18. © 2015 Marcio Marchini
Passo 8: Repetir a dose pra camada Controller - impl
Thin Controllers (fat Models)
• Adicionam auth, param sanity, usam Engine.
• Adaptam de REST p/ sua linguagem
• Single Responsibility Principle!

19. © 2015 Marcio Marchini
Passo 9: Rodar Testes, Verificar Cobertura etc
Rodar da IDE
Rodar do cmd-line, etc. Varia de
IDE pra IDE, de runtime pra
runtime, etc (uso Paver)

20. © 2015 Marcio Marchini
ALERTA: Quão Bem Está Seu Grupo? Joel On Software
 The Joel Test: 12 Stepsto Better Code, By Joel Spolsky
 Wednesday, August 09, 2000
 http://www.joelonsoftware.com/articles/fog0000000043.html
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugsbefore writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmershave quiet working conditions?
9. Do you use the best toolsmoney can buy?
10.Do you have testers?
11.Do new candidateswrite code during their interview?
12.Do you do hallway usability testing?

21. © 2015 Marcio Marchini
Especificação Ágil Executável: K.I.S.S.
Resumo: No NamoroOn, Regras de Negócio são Executáveis
Pinocchio com spectest

22. © 2015 Marcio Marchini
• No seu projeto, você tem um macarrão (caro de manter $$$) ou
algo bem arquitetado (e maleável $)?
• Coisasóbviasajudam: Injeção de Dependência no constructor:
RankingController(ranking_engine = RankingEngine())
• Camadas:
API First = Camadas Independentes e Boas Métricas
Na www.Nexxera.com estamosusando ferramental para
projetar & garantir camadase métricas, em Python!

23. © 2015 Marcio Marchini
• “Faça 2 UIs” – Vai dificultar você seguir o caminho do mal (da
massaroca)
• Ou: Consigo fazer um app console (sem GUI) usando somente
sua camada modelo, sem sua camada REST?
• Ou: Consigo fazer um app de GUI (Python+Qt?) usando somente
sua camada modelo, sem sua camada REST?
• Ou: você pensa/modela em camadas/componentesbottom-up
SRP, ou “fazer um sistema”?
• Ou: consigo dar um “pip install” da sua camada modelo sem
trazer a capa RESTjunto?
Heurística do Marchini

24. © 2015 Marcio Marchini
Resumo da Mensagem
APIs, BDD, Camadas  ROI:
“Pay me now ($) or pay me later ($$$)”
Because, one way or another, you will pay…
“If you think it's expensive to hire a
professional to do the job, wait until you
hire an amateur.”

25. © 2015 Marcio Marchini
FIM : Resumindo. Perguntas/Comentários?
BDD é TDD do jeito certo.
BDD sozinho não garante boas APIs!
Use BDD de componentes/APIs (API First)
para arquitetura LEGO
Use BDD polimórfico multi-camada MVC
Verbos e Substativos do Domínio do
Problema (legibilidade, DDD)
Não esqueça do apêndice! (próximo slide)

26. © 2015 Marcio Marchini
Apêndice: Alguns Links e Comentários Úteis
• API First
http://www.eclipsecon.org/2005/presentations/EclipseCon2005_12.2APIFirst.pd
f
• How to Design a Good API and Why it Matters
http://lcsd05.cs.tamu.edu/slides/keynote.pdf ,
https://www.youtube.com/watch?v=aAb7hSCtvGw
• Web API Design
http://blog.apigee.com/detail/announcement_new_ebook_on_web_api_design/
• Python Pinocchio e SpecTest: https://github.com/mkwiatkowski/pinocchio
• Python Behave http://pythonhosted.org/behave/
• Python Lettuce http://lettuce.it
• Robot Framework (ATDD): http://robotframework.org
• Investigue o modelo canônico de User Stories: “As a <role> I should be able to
<action> so that <business value>”
• Investigue o modelo canônico de Acceptance Criteria: “Given <pre-condition(s)>
When <action(s)> Then <post-condition(s)>”
• Curso Better Developer  : http://www.betterdeveloper.net/cursos.html
”Quem Lê Sabe Mais…” – Sabedoria repassada pelo papa Marchini