BDD-NamoroOn

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

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

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!)

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”

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)

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

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. ...

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!!!)

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!!!

Cada teste exercita uma ou mais
das APIs para completar toda
uma Use Case da API:
rank_as_liked ... ranked_as_liked?

Vários testes da API (use cases):

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>

Passo 6: Implementando a Camada Modelo
A API da Engine:

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)

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)

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)

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)

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!

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)

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?

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

• 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!

• “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

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.”

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)

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

BDD-NamoroOn

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a BDD-NamoroOn (20)

Mais de Marcio Marchini (8)

BDD-NamoroOn

Notas do Editor