Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TDD - Desenvolvimento Orientado por Testes

TDD - Desenvolvimento Orientado por Testes

Introdução à TDD, explicando o que é e situando-o dentro dos diversos tipos de testes.

Avatar for Daniel Capo Sobral

Daniel Capo Sobral

June 04, 2012
Tweet

More Decks by Daniel Capo Sobral

Other Decks in Programming

Transcript

  1. Taxonomias • Funcional • Não Funcional Objeto de teste •

    Automático • Manual Execução • Caixa Preta • Caixa Branca • Caixa Cinza Informação sobre o sistema • Exploratório • Pré-definido Planejamento • Teste Primeiro • Teste por Último Momento de escrita • Qualitativo • Quantitativo Resultado • Estático (tipos, provas) • Dinâmico Execução do código testado • Estado • Interação Comportamento observado • Verificação • Validação Contratado vs Desejado • TDD • ATDD • BDD Técnica de Escrita
  2. O que é TDD? Técnica de Desenvolvimento de Software Teste

    Primeiro Teste Unitário Automatizado TDD é sobre como escrever código de aplicação. TDD não é sobre como escrever testes!
  3. Porque não fazer TDD? • Como escrever testes? • Como

    escrever código testável? • Como usar as ferramentas? • Como se faz TDD? Curva de Aprendizado Íngreme: • Mais linhas de código • Interrupções constantes Menor Produtividade • Mais código, mais manutenção • Mudanças de arquitetura quebram testes! • Mudanças de comportamento quebram testes! Maior Custo de Manutenção
  4. Porque fazer TDD? • Confiança para efetuar mudanças • Testes

    resguardam contra regressão Menor Custo de Manutenção • YAGNI! (You Ain’t Gonna Need It!) significa menos desperdício • Menos tempo corrigindo bugs: estava funcionando a cinco minutos atrás! Maior Produtividade • Mais testes leva a menos bugs • Testes unitários compreensivos resultam em baixo acoplamento Maior Qualidade
  5. O que dizem os estudos? Maior Qualidade? • Inconclusivo •

    Boa correlação, mas... • Isolamento • TDD ou outras práticas ágeis? • TDD ou número de testes? • Mais testes levam a menos bugs? Confirmado. • Curva de aprendizado íngreme dificulta grupos de controle E a Produtividade? • Inconclusivo • Conforme estudo, melhor, pior ou indiferente
  6. Dificuldades Onde começar? O que testar? O que não testar?

    Quanto se testar de cada vez? Que nome dar aos testes? Como entender porque o teste falhou? Como separar uma unidade de suas dependências? Fonte: Introducing BDD, Dan North
  7. O que é um bom teste unitário? Deve ser fácil

    de implementar. Deve ser automatizável e reproduzível de forma confiável. Qualquer um deve ser capaz de executá-lo, sem setups complicados. Deve ser executável com um simples click. Deve executar rapidamente. Uma vez escrito, deve ser preservado para uso futuro. Fonte: The Art of Unit Testing, Roy Osherove
  8. Teste (automatizado) é Código Em outras palavras, deve receber as

    mesmas atenções que o código da aplicação! Atenção com Manutenção Qualidade Legibilidade Refatoração Code Rot Arcabouço, Armação, Andaime Ajuda a construir Removido ao fim da construção Mas software sem manutenção é software morto!
  9. Removendo dependências: Fakes Stubs Teste de estado Mocks Teste de

    Interação Asserções Espelhamento Como? Injeção de Dependências
  10. Três leis de TDD Você não pode escrever código de

    aplicação mais do que o suficiente para fazer um teste unitário passar. Você não pode escrever código de teste mais do que o necessário para falhar; falhar compilação também conta. Você não pode escrever código de aplicação exceto para fazer passar um teste unitário. Segundo Robert Martin
  11. Três fases de TDD Vermelho • Escrever código de teste

    para evidenciar falha Verde • Escrever código de aplicação para corrigir falha Azul • Refactoring de código (aplicação e testes)
  12. Fluxo de TDD Escrever teste Escrever aplicação Refatoração (aplicação e

    testes) Falhou? Passou? Sim Não Não Sim Executa teste Executa teste Passou? Executa teste Sim Não Sim
  13. Demonstração Jogo de Boliche  Regras:  10 jogadas (frames)

     1 ou 2 arremessos por jogada (1ª à 9ª)  2 ou 3 arremessos na 10ª jogada  10 pinos  1 ponto por pino derrubado  Spare – 10 pinos derrubados em 2 arremessos  10 pontos + próximo arremesso  Strike – 10 pinos derrubados em 1 arremesso  10 pontos + 2 próximos arremessos
  14. Referências  Clean Coders (Robert Martin)  Making Software: What

    Really Works, and Why We Believe It (Andy Oram & Greg Wilson)  The Art of Unit Testing: with Examples in .Net (Roy Osherove)  Introducing BDD (Dan North)  Wikipedia (duh!)  Test Driven Development: By Example (Kent Beck)