1. Test-drivendevelopment&Mocking

2. Por que utilizar? Faz você pensar sobre o comportamento requisitado Reduz o código “especulativo” Provê uma documentação interna Melhora na qualidade

3. Alguns equívocos Escrever testes após o código de produção é a mesma coisa TDD é sobre testes TDD não é útil para o desing de software Torna lento o desenvolvimento de software É impossível atingir 100% de cobertura nos testes

5. Figure o que você quer fazer

6. Teste

7. Escreva um teste que expresse o seu design

8. Deve falhar

9. Implemente

10. Escreva o código de produção

11. Teste novamente

13. Figure o que está acontecendo

14. Teste

15. Escreva um teste que simule a falha

16. Deve falhar

17. Corrija o defeito

18. Escreva o código de produção para corrigi-lo

19. Teste novamente

21. Analise o código legado. Continue confuso.

22. Teste

23. Escreva um teste para entender o comportamento

24. Deve falhar

25. Adapte o teste

26. Iterativamente

27. Até passar

29. Mova-se (muito) devagar

30. Esteja preparado para abandonar suas melhorias

31. Acompanhe como uma trilha a cobertura de testes

32. O quanto do código de produção está coberto?

33. Quais áreas ainda precisam de testes?

35. Mock Objects Verificam a interação entre objetos e não os seus estados Devem ser projetados como uma interface; e não para um objeto específico Especificam valores de retornos, exceções, números de chamadas, ordem das chamada

37. Uma expectativa por teste

38. Não teste métodos privados

39. Não utilize mocks para todas as coisas

40. Diga ao invés de perguntar

41. Especifique o mínimo possível em um teste

42. Preste atenção aos “test smells”