Test-driven Development

Presented @ W3BOX. PT-BR

Transcript

1. Test-driven Development Felipe Elias Philipp @ W3BOX 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 programador escreve um teste que falhe. O ciclo de TDD Friday, January 29, 2010
14. • O programador escreve um teste que falhe. • O programador escreve o código mais simples possível para o teste passar. O ciclo de TDD Friday, January 29, 2010
15. • 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. O ciclo de TDD Friday, January 29, 2010
16. • 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. O ciclo de TDD 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 código Facilidade na refatoração Friday, January 29, 2010
21. Os testes servem como especificação e são executáveis! 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