Test-Driven Development (TDD)

Desenvolvimento Guiadopor Testes

Igo Coelhoigocoelho@gmail.comhttp://www.igocoelho.com.br

  

O que é TDD?

  

Regras fundamentais do TDD

Escreva o teste da implementação ANTES de escrevê-la

Escreva somente código suficiente para o teste passar e nada além disso

Escreva testes pequenos: teste a menor quantidade possível de código de cada vez

Escreva testes muito rápidos: não devem demorar mais do que alguns segundos para serem executados

  

Etapas da programação com TDD

1. Criar um teste

2. Executar todos os testes da aplicação para ver o teste falhar

3. Escrever a implementação testada

4. Executar os testes para ver se todos passarão

5. Refactoring

6. Executar os testes novamente para ver se eles continuam passando

  

Implementação

Design

Teste

Testes

  

Teste

Design

Implementação

TDD

  

Teste

Design

Implementação

TDD

Teste

  

Teste

Design

Implementação

TDD

Teste

  

Demonstração

  

  

  

  

  

  

  

  

  

  

Consequências

  

Consequências:

Suite de regressão Testes completos podem ser executados no build:

aplicação não sobe para produção se não passar no teste de regressão

Testes também pode ser feitos na IDE Não há necessidade de executar o build da

aplicação para execução dos testes

Bugs são encontrados com maior facilidade e corrigidos com maior velocidade

Bugs comprovados por testes unitários

  

Consequências:

Código mais testável Estimula um design melhor

Força que os designs antigos que são pouco testáveis sejam refatorados

Facilita o refactoring

Evita o “overdesign” Só se escreve código suficiente para o teste passar

Evita que o desenvolvedor tente advinhar o futuo

Colabora com a documentação

  

Conclusões

  

Conclusões:

Colabora para o aumento da qualidade dos sistemas

Desenvolvedores ficam mais corajosos e confiantes ao programar!

Software cresce de forma ordenada e com qualidade de design

Software se adapta com mais facilidade a mudanças

  

Conclusões:

Demora mais?

  

Conclusões:

Demora mais? No início é necessário escrever muitos testes

  

Conclusões:

Demora mais? No início é necessário escrever muitos testes Depois da inércia a suite de regressão está

pronta e escrevem-se menos testes

  

Conclusões:

Demora mais? No início é necessário escrever muitos testes Depois da inércia a suite de regressão está

pronta e escrevem-se menos testes Certeza de que a implementação está

funcionando

  

Conclusões:

Demora mais? No início é necessário escrever muitos testes Depois da inércia a suite de regressão está

pronta e escrevem-se menos testes Certeza de que a implementação está

funcionando Maioria dos bugs encontrados em tempo de

desenvolvimento

  

Conclusões:

Demora mais? No início é necessário escrever muitos testes Depois da inércia a suite de regressão está

pronta e escrevem-se menos testes Certeza de que a implementação está

funcionando Maioria dos bugs encontrados em tempo de

desenvolvimento Bugs de produção são encontrados e corrigidos

com muito mais velocidade

  

Conclusões:

Demora mais? No início é necessário escrever muitos testes Depois da inércia a suite de regressão está

pronta e escrevem-se menos testes Certeza de que a implementação está

funcionando Maioria dos bugs encontrados em tempo de

desenvolvimento Bugs de produção são encontrados e corrigidos

com muito mais velocidade

No final das contas com a pratica demora-se menos tempo com mais qualidade

  

Perguntas?

  

Obrigado!