Test-drivendevelopment&Mocking<br />
Por que utilizar?<br />Faz você pensar sobre o comportamento requisitado<br />Reduz o código “especulativo”<br />Provê uma...
Alguns equívocos<br />Escrever testes após o código de produção é a mesma coisa<br />TDD é sobre testes<br />TDD não é úti...
Como isto funciona tradicionalmente?<br /><ul><li>Design
Figure o que você quer fazer
Teste
Escreva um teste que expresse o seu design
Deve falhar
Implemente
Escreva o código de produção
Teste novamente
Próximos SlideShares
Carregando em…5
×

Test-driven development & Mocking

1.553 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.553
No SlideShare
0
A partir de incorporações
0
Número de incorporações
599
Ações
Compartilhamentos
0
Downloads
14
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Test-driven development & Mocking

  1. 1. Test-drivendevelopment&Mocking<br />
  2. 2. Por que utilizar?<br />Faz você pensar sobre o comportamento requisitado<br />Reduz o código “especulativo”<br />Provê uma documentação interna<br />Melhora na qualidade<br />
  3. 3. Alguns equívocos<br />Escrever testes após o código de produção é a mesma coisa<br />TDD é sobre testes<br />TDD não é útil para o desing de software<br />Torna lento o desenvolvimento de software<br />É impossível atingir 100% de cobertura nos testes<br />
  4. 4. Como isto funciona tradicionalmente?<br /><ul><li>Design
  5. 5. Figure o que você quer fazer
  6. 6. Teste
  7. 7. Escreva um teste que expresse o seu design
  8. 8. Deve falhar
  9. 9. Implemente
  10. 10. Escreva o código de produção
  11. 11. Teste novamente
  12. 12. Deve passar</li></li></ul><li>E se um defeito for encontrado?<br /><ul><li>Entenda o defeito
  13. 13. Figure o que está acontecendo
  14. 14. Teste
  15. 15. Escreva um teste que simule a falha
  16. 16. Deve falhar
  17. 17. Corrija o defeito
  18. 18. Escreva o código de produção para corrigi-lo
  19. 19. Teste novamente
  20. 20. Deve passar</li></li></ul><li>E como eu faço com um sistema sem testes?<br /><ul><li>WTF?
  21. 21. Analise o código legado. Continue confuso.
  22. 22. Teste
  23. 23. Escreva um teste para entender o comportamento
  24. 24. Deve falhar
  25. 25. Adapte o teste
  26. 26. Iterativamente
  27. 27. Até passar
  28. 28. Vá para a próxima funcionalidade</li></li></ul><li>Testes feitos depois, definitivamente, não é o mesmo que TDD <br /><ul><li>Cuide excessivamente
  29. 29. Mova-se (muito) devagar
  30. 30. Esteja preparado para abandonar suas melhorias
  31. 31. Acompanhe como uma trilha a cobertura de testes
  32. 32. O quanto do código de produção está coberto?
  33. 33. Quais áreas ainda precisam de testes?
  34. 34. Onde estão os maiores riscos?</li></li></ul><li>Dublês de teste (test doubles)<br />Dummy<br />Objeto que passa de um lado pro outro sem ser utilizado<br />Fake<br />Objeto real, muito próximo a realidade (ou até melhor), mas...<br />Stub<br />Objeto implementado para simular comportamento,armazenando estado para verificação<br />Mock<br />objetos pré-programados com informações que formam uma especificação das chamadas que esperam receber.<br />
  35. 35. Mock Objects<br />Verificam a interação entre objetos e não os seus estados<br />Devem ser projetados como uma interface; e não para um objeto específico<br />Especificam valores de retornos, exceções, números de chamadas, ordem das chamada<br />
  36. 36. Boas práticas<br /><ul><li>Verifique o comportamento e não a implementação
  37. 37. Uma expectativa por teste
  38. 38. Não teste métodos privados
  39. 39. Não utilize mocks para todas as coisas
  40. 40. Diga ao invés de perguntar
  41. 41. Especifique o mínimo possível em um teste
  42. 42. Preste atenção aos “test smells”
  43. 43. Evite o uso de getters</li></li></ul><li>Resumo<br />Nunca escreve um código sem um teste que falhe<br />Inicie de fora pra dentro, com os testes de aceitação<br />Projeto o design utilizando mocks de acordo com a necessidade<br />Os testes devem ser especificações descritivas<br />Falhe - Implemente - Refatore<br />

×