Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BDD-NamoroOn

651 views

Published on

  • Be the first to comment

BDD-NamoroOn

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 11. © 2015 Marcio Marchini Passo 5: Modelando as Use Cases da API com Testes Vários testes da API (use cases):
  12. 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. 13. © 2015 Marcio Marchini Passo 6: Implementando a Camada Modelo A API da Engine:
  14. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×