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