Carregado porFelipe Elias Philipp
Test-driven Development - Introdução
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.
Test-driven Development - Introdução
- 1. Test-driven Felipe Elias Philipp @ W3BOX Development 15/01/2010 Friday, January 29, 2010
- 2. O dia adia 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, January29, 2010
- 11. TDD - Test-driven Development Friday, January 29, 2010
- 12. “É uma técnicade 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 deTDD • O programador escreve um teste que falhe. Friday, January 29, 2010
- 14. O ciclo deTDD • 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 deTDD • 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 deTDD • 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 vantagensdo 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 servemcomo 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, January29, 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, January29, 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.