Contenu connexe Similaire à BDD-NamoroOn (20) Plus de Marcio Marchini (8) BDD-NamoroOn1. © 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
Notes de l'éditeur Marchini entra e mostra a Agenda, começa a apresentar.
Marchini entra e mostra a Agenda, começa a apresentar.
Marchini entra e mostra a Agenda, começa a apresentar.