O documento descreve o desenvolvimento guiado por testes (TDD), definindo suas regras e etapas. Ele explica que TDD envolve escrever testes antes da implementação para forçar um design melhor e encontrar bugs mais rápido, resultando em código de maior qualidade apesar de possivelmente demorar mais no início.

1. Desenvolvimento Guiado
por Testes
Test-Driven Development (TDD)
Igo Coelho
igocoelho@gmail.com
http://www.igocoelho.com.br

2. O que é TDD?

3. 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

4. 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

5. Testes
Design
Implementação
Teste

6. TDD
Design
Teste
Implementação

7. TDD
Design
Teste
Implementação
Teste

8. TDD
Design
Teste Teste
Implementação

9. Demonstração

19. Consequências

20. 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


21. 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


22. Conclusões

23. 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

24. Conclusões:
Demora mais?


25. Conclusões:
Demora mais?

No início é necessário escrever muitos testes


26. 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

27. 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

28. 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

29. 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

30. 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

31. Perguntas?

32. Obrigado!