Introdução ao TDD

2,295
-1

Published on

Slides da palestra "Introdução ao TDD - O método de construção de software guiado por testes".

Introdução ao TDD

  1. 2. Agenda <ul><ul><li>O que é TDD? </li></ul></ul><ul><ul><li>Quem inventou? </li></ul></ul><ul><ul><li>Espiral da morte </li></ul></ul><ul><ul><li>Benefícios </li></ul></ul><ul><ul><li>Padrões do TDD </li></ul></ul><ul><ul><li>Red Bar Patterns </li></ul></ul><ul><ul><li>Testing Patterns </li></ul></ul><ul><ul><li>Green Bar Patterns </li></ul></ul><ul><ul><li>Padrões xUnit </li></ul></ul><ul><ul><li>Refatoração </li></ul></ul><ul><ul><li>Dominando TDD </li></ul></ul><ul><ul><li>Como aprender TDD </li></ul></ul>
  2. 3. O que é TDD? <ul><ul><li>Técnica de desenvolvimento de software </li></ul></ul><ul><ul><li>Testes unitários automatizados </li></ul></ul><ul><ul><li>Test-first programming (da XP) </li></ul></ul><ul><ul><li>Processo formado por pequenas iterações </li></ul></ul>
  3. 4. O que é TDD? <ul><ul><li>Já sei, é um método para testar software! </li></ul></ul>
  4. 5. O que é TDD? <ul><ul><li>Não é um método para testar software </li></ul></ul><ul><ul><li>É um método para construir software </li></ul></ul>
  5. 6. O que é TDD? <ul><ul><li>Através do processo “vermelho-verde-refatorar” </li></ul></ul>
  6. 7. O que é TDD? <ul><ul><li>Com “código limpo que funciona” (Ron Jefrries) </li></ul></ul>
  7. 8. Quem inventou? <ul><ul><li>Não sei… </li></ul></ul><ul><ul><li>Mas um criador de cabras que redescobriu TDD. </li></ul></ul><ul><ul><li>@kentbeck </li></ul></ul>
  8. 9. Espiral da morte “sem tempo para testar”
  9. 10. Benefícios <ul><ul><li>Testes unitários sempre atualizados </li></ul></ul><ul><ul><li>Design guiado pelos testes </li></ul></ul><ul><ul><li>Aumento de confiança </li></ul></ul><ul><ul><li>Qualidade de código </li></ul></ul><ul><ul><li>Baixo acoplamento </li></ul></ul><ul><ul><li>Alta coesão </li></ul></ul><ul><ul><li>Código limpo </li></ul></ul><ul><ul><li>Testes são especificações </li></ul></ul>
  10. 11. Padrões do TDD <ul><ul><li>Crie uma lista de testes </li></ul></ul><ul><ul><li>Faça um brainstorm </li></ul></ul><ul><ul><li>Identifique e anote todos os testes que você precisará escrever </li></ul></ul><ul><ul><li>Faça isso para uma mesma classe ou método a ser testado </li></ul></ul><ul><ul><li>Durante o desenvolvimento, você pode adicionar novos testes a essa lista </li></ul></ul>
  11. 12. Padrões do TDD <ul><ul><li>Crie testes isolados uns dos outros </li></ul></ul><ul><ul><li>Um teste não pode depender de outro </li></ul></ul><ul><ul><li>Deve ser possível executar um teste isoladamente </li></ul></ul>
  12. 13. Padrões do TDD <ul><ul><li>Teste primeiro </li></ul></ul><ul><ul><li>Escreva o teste antes do código que é para ser testado </li></ul></ul><ul><ul><li>É uma oportunidade para pensar no design das classes </li></ul></ul><ul><ul><li>Uma forma de controlar o escopo do que será implementado </li></ul></ul>
  13. 14. Padrões do TDD <ul><ul><li>Assertiva primeiro </li></ul></ul><ul><ul><li>Pense primeiro no sucesso do teste </li></ul></ul><ul><ul><li>Depois pense se vai precisar de um método, de uma classe, os nomes dos parâmetros, etc </li></ul></ul>
  14. 15. Padrões do TDD <ul><ul><li>Como assim? </li></ul></ul>
  15. 16. Padrões do TDD <ul><ul><li>Como assim? </li></ul></ul>
  16. 17. Padrões do TDD <ul><ul><li>Dados para teste </li></ul></ul><ul><ul><li>Não use números mágicos </li></ul></ul><ul><ul><li>Evite passar o mesmo valor para diferentes parâmetros </li></ul></ul><ul><ul><li>Use dados do mundo real </li></ul></ul>
  17. 18. Padrões do TDD <ul><ul><li>Use dados evidentes </li></ul></ul><ul><ul><li>Testes são para pessoas, não para computadores </li></ul></ul><ul><ul><li>Escreva na assertiva uma expressão não só que representa o valor final esperado, mas o que ele significa </li></ul></ul>
  18. 19. Padrões do TDD <ul><ul><li>Use dados evidentes </li></ul></ul>
  19. 20. Padrões do TDD <ul><ul><li>Ao invés de… </li></ul></ul>
  20. 21. Padrões do TDD <ul><ul><li>Live code! </li></ul></ul>
  21. 22. Red Bar Patterns <ul><ul><li>Quando e onde escrever os testes? </li></ul></ul><ul><ul><li>Quando parar? </li></ul></ul>
  22. 23. Red Bar Patterns <ul><ul><li>Um passo de cada vez </li></ul></ul><ul><ul><li>Qual o próximo teste? </li></ul></ul><ul><ul><li>O que você está confiante e vai lhe ensinar algo </li></ul></ul><ul><ul><li>Para cada pessoa a resposta é diferente </li></ul></ul><ul><ul><li>Cada teste deve representar um passo em direção ao objetivo final </li></ul></ul>
  23. 24. Red Bar Patterns <ul><ul><li>Primeiro teste </li></ul></ul><ul><ul><li>Não comece pelo mais completo </li></ul></ul><ul><ul><li>Comece pelo menor </li></ul></ul><ul><ul><li>Comece pelo mais simples </li></ul></ul>
  24. 25. Red Bar Patterns <ul><ul><li>Teste de regressão </li></ul></ul><ul><ul><li>Se um defeito for encontrado, escreva um pequeno teste que falha, execute e depois implemente a correção </li></ul></ul><ul><ul><li>Para escrever o teste, pense em como você teria feito se fosse no passado </li></ul></ul>
  25. 26. Testing Patterns <ul><ul><li>Técnicas mais detalhadas de como escrever testes </li></ul></ul><ul><ul><li>Hum… legal! </li></ul></ul>
  26. 27. Testing Patterns <ul><ul><li>Testes menores </li></ul></ul><ul><ul><li>Se o teste ficou grande demais, deixe-o e escreva um pequeno que representa parte dele </li></ul></ul><ul><ul><li>O ciclo “verde-vermelho-refatorar” deve ser rápido </li></ul></ul>
  27. 28. Testing Patterns <ul><ul><li>Objetos dublês (mock) </li></ul></ul><ul><ul><li>Como testar objetos que dependem de recursos externos, caros e complicados? </li></ul></ul><ul><ul><li>Crie uma versão falsa deles que retornam constantes </li></ul></ul><ul><ul><li>Existem diversas ferramentas para ajudar a fazer isso (eu uso o Mockito) </li></ul></ul>
  28. 29. Green Bar Patterns <ul><ul><li>Padrões para fazer o teste passar </li></ul></ul><ul><ul><li>Como fazer um teste vermelho ficar verde rapidamente? </li></ul></ul>
  29. 30. Green Bar Patterns <ul><ul><li>Falsifique até construir realmente </li></ul></ul><ul><ul><li>Implemente um código falso que retorna uma constante (só para fazer o teste passar) </li></ul></ul><ul><ul><li>Ter algo rodando é melhor que não ter </li></ul></ul><ul><ul><li>Isso gera um bom efeito psicológico </li></ul></ul>
  30. 31. Green Bar Patterns <ul><ul><li>Triangulação </li></ul></ul><ul><ul><li>Abstraia métodos quando tiver dois ou mais testes </li></ul></ul><ul><ul><li>Quando fazemos isso, somos forçados a implementar algo que realmente funciona (sem falsificação) </li></ul></ul>
  31. 32. Green Bar Patterns <ul><ul><li>Implementação óbvia </li></ul></ul><ul><ul><li>Como implementar operações simples? </li></ul></ul><ul><ul><li>Apenas codifique a solução diretamente </li></ul></ul><ul><ul><li>Se sabe o que precisa digitar, então faça </li></ul></ul><ul><ul><li>Prepare-se para voltar atrás e dar um passo menor se suas mão não conseguirem acompanhar seu cérebro </li></ul></ul>
  32. 33. Padrões xUnit <ul><ul><li>xUnit é o nome genérico para ferramentas de testes unitários </li></ul></ul><ul><ul><li>Vamos conhecer alguns padrões para usar ferramentas da família xUnit </li></ul></ul>
  33. 34. Padrões xUnit <ul><ul><li>Asserções </li></ul></ul><ul><ul><li>Escreva expressões booleanas que automatizam o julgamento sobre quando o código funciona </li></ul></ul><ul><ul><li>Deve ser true se estiver ok e false quando houver algum problema </li></ul></ul><ul><ul><li>Seja específico na asserção </li></ul></ul><ul><ul><li>Inclua mensagens informativas na asserção </li></ul></ul>
  34. 35. Padrões xUnit <ul><ul><li>Método de teste </li></ul></ul><ul><ul><li>O nome do método pode começar com “test”, “deve”, “should” ou nada disso </li></ul></ul><ul><ul><li>O nome do método deve comunicar o que está sendo testado </li></ul></ul><ul><ul><li>O código de teste deve ser curto e fácil de entender </li></ul></ul>
  35. 36. Refatoração <ul><ul><li>Refatorar é melhorar o design do sistema sem alterar o comportamento </li></ul></ul><ul><ul><li>Como mudar o design do sistema radicalmente ou em pequenos passos? </li></ul></ul><ul><ul><li>Ao refatorar, os testes devem continuar verdes </li></ul></ul><ul><ul><li>Refatoramos para melhorar legibilidade, facilitar manutenção e melhorar performance </li></ul></ul>
  36. 37. Refatoração <ul><ul><li>Reconcilie diferenças </li></ul></ul><ul><ul><li>Duas partes de códigos iguais podem ser eliminadas </li></ul></ul><ul><ul><li>Dois loops similares, ao fazerem eles idênticos, podem ser fundidos em um só </li></ul></ul><ul><ul><li>Duas condições similares, ao fazerem idênticas, uma pode ser eliminada </li></ul></ul><ul><ul><li>Dois métodos ou classes similares, ao fazerem idênticos, um pode ser eliminado </li></ul></ul>
  37. 38. Refatoração <ul><ul><li>Extraia métodos </li></ul></ul><ul><ul><li>Como fazer um método longo e complicado fácil de ser lido? </li></ul></ul><ul><ul><li>Encontre uma parte do código que faça sentido ter seu próprio método (blocos em loops e caminhos de condições são candidatos) </li></ul></ul><ul><ul><li>Deixe o teste sempre verde durante as mudanças </li></ul></ul>
  38. 39. Dominando TDD <ul><ul><li>Perguntas que surgem ao iniciar com TDD. </li></ul></ul>
  39. 40. Dominando TDD <ul><ul><li>Qual o tamanho ideal dos passos? </li></ul></ul><ul><ul><li>Não existe uma regra </li></ul></ul><ul><ul><li>Mas a tendência é que sejam passos pequenos </li></ul></ul><ul><ul><li>Quando sentir confortável, você poderá dar passos um pouco maiores </li></ul></ul><ul><ul><li>Ferramentas ajudam a pular etapas na fase de refatoração </li></ul></ul>
  40. 41. Dominando TDD <ul><ul><li>O que você precisa testar? </li></ul></ul><ul><ul><li>Você encontrará essa resposta praticando </li></ul></ul><ul><ul><li>Teste condições, loops, operações, polimorfismo </li></ul></ul><ul><ul><li>Teste apenas códigos que você escreve </li></ul></ul>
  41. 42. Dominando TDD <ul><ul><li>Como você sabe se tem bons testes? </li></ul></ul><ul><ul><li>Alguns atributos que sugerem testes ruins: </li></ul></ul><ul><ul><li>Código de configuração longo ou duplicado </li></ul></ul><ul><ul><li>Testes demorados para executar </li></ul></ul><ul><ul><li>Testes frágeis (que dependem do resultado de outros) </li></ul></ul>
  42. 43. Dominando TDD <ul><ul><li>Como migrar um projeto existente para usar TDD? </li></ul></ul><ul><ul><li>O maior problema é que códigos escritos sem pensar nos testes normalmente são difíceis de testar </li></ul></ul><ul><ul><li>Mudanças no código são perigosas porque não existem testes para garantir o funcionamento </li></ul></ul><ul><ul><li>Se tiver partes do sistema que precisam ser simplificadas mas não precisam de mudança no momento, não faça nada </li></ul></ul><ul><ul><li>Quando precisar modificar um método, implemente os testes antes </li></ul></ul><ul><ul><li>Faça testes em nível de aplicação para garantir um certo nível de confiança </li></ul></ul>
  43. 44. Como aprender TDD <ul><ul><li>Leia livros </li></ul></ul>
  44. 45. Como aprender TDD <ul><ul><li>Assista vídeos na internet de pessoas usando TDD </li></ul></ul>
  45. 46. Como aprender TDD <ul><ul><li>Estude códigos de projetos que usam TDD </li></ul></ul>
  46. 47. Como aprender TDD <ul><ul><li>Pratique muito </li></ul></ul>
  47. 48. Perguntas? Thiago Faria de Andrade [email_address] @thiagofandrade Obrigado! www.algaworks.com @algaworks Normandes Júnior [email_address] @normandesjr

×