Test-driven Development - Introdução

1,694 views

Published on

Breve introdução ao TDD

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,694
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Test-driven Development - Introdução

  1. 1. Test-driven Felipe Elias Philipp @ W3BOX Development 15/01/2010 Friday, January 29, 2010
  2. 2. O dia a dia de um desenvolvedor Friday, January 29, 2010
  3. 3. Pensamentos comuns (e errados) sobre testes Friday, January 29, 2010
  4. 4. Pensamentos comuns (e errados) sobre testes • Eu sou desenvolvedor, não sou testador. Friday, January 29, 2010
  5. 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. 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. 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. 8. Quem deve testar? Quem é responsável pelos testes? Friday, January 29, 2010
  9. 9. Por que o desenvolvedor deve testar? Friday, January 29, 2010
  10. 10. Como testar? Friday, January 29, 2010
  11. 11. TDD - Test-driven Development Friday, January 29, 2010
  12. 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. 13. O ciclo de TDD • O programador escreve um teste que falhe. Friday, January 29, 2010
  14. 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. 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. 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. 17. Quais as vantagens do TDD? Friday, January 29, 2010
  18. 18. Mais segurança e confiança no código Se alguém introduzir um bug, o teste falhará. Friday, January 29, 2010
  19. 19. Desacoplamento entre os componentes Sem aquela história: “mexe de um lado, estraga de outro” Friday, January 29, 2010
  20. 20. Melhor qualidade do Facilidade na refatoração código Friday, January 29, 2010
  21. 21. Os testes servem como e são executáveis! especificação Friday, January 29, 2010
  22. 22. TDD não é... • ... teste caixa preta. Friday, January 29, 2010
  23. 23. TDD não é... • ... teste caixa preta. • ... teste de aceitação. Friday, January 29, 2010
  24. 24. TDD não é... • ... teste caixa preta. • ... teste de aceitação. • ... perda de tempo. Friday, January 29, 2010
  25. 25. TDD não é... • ... teste caixa preta. • ... teste de aceitação. • ... perda de tempo. • ... bala de prata. Friday, January 29, 2010
  26. 26. Algumas dicas Friday, January 29, 2010
  27. 27. Algumas dicas • Faça um brainstorm antes para pensar nos testes possíveis. Friday, January 29, 2010
  28. 28. Algumas dicas • Faça um brainstorm antes para pensar nos testes possíveis. • Escreva um teste legível. Friday, January 29, 2010
  29. 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. 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. 31. Alguns mantras Friday, January 29, 2010
  32. 32. Alguns mantras • Não tente resolver todos os problemas de uma vez. Friday, January 29, 2010
  33. 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. 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. 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. 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. 37. Perguntas? Friday, January 29, 2010

×