O documento discute os benefícios do desenvolvimento guiado por testes (TDD), onde os testes são escritos antes do código. Ele explica que o desenvolvedor deve testar seu próprio código e descreve o ciclo básico do TDD. Além disso, fornece dicas e mantras para aplicar a técnica de TDD de forma efetiva.

1. Test-driven
Felipe Elias Philipp @ W3BOX
Development
15/01/2010
Friday, January 29, 2010

2. O dia a dia de um
desenvolvedor
Friday, January 29, 2010

3. Pensamentos comuns
(e errados) sobre testes
Friday, January 29, 2010

4. Pensamentos comuns
(e errados) sobre testes
• Eu sou desenvolvedor, não sou
testador.
Friday, January 29, 2010

5. Pensamentos comuns
(e errados) sobre testes
• Eu sou desenvolvedor, não sou
testador.
• Vou deixar alguém que
conheça as regras de negócio
testar.
Friday, January 29, 2010

6. Pensamentos comuns
(e errados) sobre testes
• Eu sou desenvolvedor, não sou
testador.
• Vou deixar alguém que
conheça as regras de negócio
testar.
• É melhor deixar outra pessoa
testar.
Friday, January 29, 2010

7. Pensamentos comuns
(e errados) sobre testes
• Eu sou desenvolvedor, não sou
testador.
• Vou deixar alguém que
conheça as regras de negócio
testar.
• É melhor deixar outra pessoa
testar.
• Não tenho tempo para testar.
Friday, January 29, 2010

8. Quem deve testar? Quem é responsável pelos testes?
Friday, January 29, 2010

9. Por que o
desenvolvedor deve
testar?
Friday, January 29, 2010

10. Como testar?
Friday, January 29, 2010

11. TDD - Test-driven
Development
Friday, January 29, 2010

12. “É uma técnica de desenvolvimento de software em que se
desenvolve em pequenas iterações, onde primeiro se escreve o
teste e depois o código. Cada iteração deve começar com um
teste que falhe, e terminar com todos os testes passando”
Friday, January 29, 2010

13. O ciclo de TDD
• O programador escreve um
teste que falhe.
Friday, January 29, 2010

14. O ciclo de TDD
• O programador escreve um
teste que falhe.
• O programador escreve o
código mais simples possível
para o teste passar.
Friday, January 29, 2010

15. O ciclo de TDD
• O programador escreve um
teste que falhe.
• O programador escreve o
código mais simples possível
para o teste passar.
• Com todos os testes passando,
refatora-se o código se
necessário.
Friday, January 29, 2010

16. O ciclo de TDD
• O programador escreve um
teste que falhe.
• O programador escreve o
código mais simples possível
para o teste passar.
• Com todos os testes passando,
refatora-se o código se
necessário.
• Ciclo se repete.
Friday, January 29, 2010

17. Quais as vantagens do TDD?
Friday, January 29, 2010

18. Mais segurança e
confiança no código
Se alguém introduzir um bug, o
teste falhará.
Friday, January 29, 2010

19. Desacoplamento
entre os
componentes
Sem aquela história: “mexe de
um lado, estraga de outro”
Friday, January 29, 2010

20. Melhor qualidade do
Facilidade na refatoração
código
Friday, January 29, 2010

21. Os testes servem como
e são executáveis!
especificação
Friday, January 29, 2010

22. TDD não é...
• ... teste caixa preta.
Friday, January 29, 2010

23. TDD não é...
• ... teste caixa preta.
• ... teste de aceitação.
Friday, January 29, 2010

24. TDD não é...
• ... teste caixa preta.
• ... teste de aceitação.
• ... perda de tempo.
Friday, January 29, 2010

25. TDD não é...
• ... teste caixa preta.
• ... teste de aceitação.
• ... perda de tempo.
• ... bala de prata.
Friday, January 29, 2010

26. Algumas dicas
Friday, January 29, 2010

27. Algumas dicas
• Faça um brainstorm antes para pensar nos testes possíveis.
Friday, January 29, 2010

28. Algumas dicas
• Faça um brainstorm antes para pensar nos testes possíveis.
• Escreva um teste legível.
Friday, January 29, 2010

29. Algumas dicas
• Faça um brainstorm antes para pensar nos testes possíveis.
• Escreva um teste legível.
• Crie testes simples de resolver.
Friday, January 29, 2010

30. Algumas dicas
• Faça um brainstorm antes para pensar nos testes possíveis.
• Escreva um teste legível.
• Crie testes simples de resolver.
• Use dados reais!
Friday, January 29, 2010

31. Alguns mantras
Friday, January 29, 2010

32. Alguns mantras
• Não tente resolver todos os problemas de uma vez.
Friday, January 29, 2010

33. Alguns mantras
• Não tente resolver todos os problemas de uma vez.
• Não vá para o próximo teste quando você ainda está resolvendo o atual.
Friday, January 29, 2010

34. Alguns mantras
• Não tente resolver todos os problemas de uma vez.
• Não vá para o próximo teste quando você ainda está resolvendo o atual.
• Se você precisa de mais funcionalidades, exponha-as em um teste.
Friday, January 29, 2010

35. Alguns mantras
• Não tente resolver todos os problemas de uma vez.
• Não vá para o próximo teste quando você ainda está resolvendo o atual.
• Se você precisa de mais funcionalidades, exponha-as em um teste.
• Se você encontrar um bug, exponha-o em um teste.
Friday, January 29, 2010

36. Alguns mantras
• Não tente resolver todos os problemas de uma vez.
• Não vá para o próximo teste quando você ainda está resolvendo o atual.
• Se você precisa de mais funcionalidades, exponha-as em um teste.
• Se você encontrar um bug, exponha-o em um teste.
• Não refatore até os testes estarem passando (verde).
Friday, January 29, 2010

37. Perguntas?
Friday, January 29, 2010