O documento apresenta uma introdução ao desenvolvimento guiado por testes (TDD). Ele discute os conceitos fundamentais do TDD como escrever testes antes da implementação, design incremental e o mantra "RED-GREEN-REFACTOR". O documento também aborda tópicos como mock objects e os benefícios do TDD como redução de bugs e incentivo à simplicidade do código.

1. Introdução ao TDD
Desenvolvimento Guiado por Testes
Palestrantes:
Breno Martinusso Magno Machado
martinusso@gmail.com magnomp@gmail.com
breno.virtoo.com blog.magnomachado.com.br
@martinusso @magnomp

2. Organização da apresentação
1. A metodologia TDD
2. Construção de Casos de
Testes

3. O que é TDD?
“TDD = Test-First + Design Incremental”
Kent Beck

4. Test-first
Escrever testes antes da implementação:
• Faz você pensar no comportamento
• Reduz código especulativo
• Documenta

5. Test-first
Escrever testes antes da implementação:
• Faz você pensar no comportamento
• Reduz código especulativo
• Documenta

6. Test-first
Escrever testes antes da implementação:
• Faz você pensar no comportamento
• Reduz código especulativo
• Documenta

7. Test-first
Escrever testes antes da implementação:
• Faz você pensar no comportamento
• Reduz código especulativo
• Documenta

8. Design incremental
• Adição de novas funcionalidades em
pequenos passos
• O conceito chave de TDD é ter um
feedback rápido das mudanças no
código

9. Design incremental
• Adição de novas funcionalidades em
pequenos passos
• O conceito chave de TDD é ter um
feedback rápido das mudanças no
código

10. Mantra do TDD
RED
GREEN
REFACTOR

11. RED
Escreva um teste que falhe

12. GREEN
Faça o teste passar

13. REFACTOR
Refatore

14. As 3 leis
Propostas por Robert C. Martin,
também conhecido como Uncle Bob.

15. Primeira lei
Antes de escrever
qualquer código de
produção, você deve
escrever um
teste unitário que falha.

16. Segunda lei
Você deve parar de
escrever o teste unitário
assim que ele falhar.
Não compilar é uma falha.

17. Terceira lei
Você deve parar de
escrever código de
produção assim que os
testes falhos passarem.

18. Mock Object

19. Mock Object
• Gera resultados não determinísticos (hora, temperatura atual...);
• Tem estados que são difíceis de criar ou reproduzir (erro de
comunicação da rede);
• É lento (um banco de dados completo que precisa ser inicializado
antes do teste);
• Ainda não existe ou pode ter comportamento alterado;
• Teriam que adicionar informações e métodos exclusivamente
para os testes (e não para sua função real).

20. Mock Object
• Gera resultados não determinísticos (hora, temperatura atual...);
• Tem estados que são difíceis de criar ou reproduzir (erro de
comunicação da rede);
• É lento (um banco de dados completo que precisa ser inicializado
antes do teste);
• Ainda não existe ou pode ter comportamento alterado;
• Teriam que adicionar informações e métodos exclusivamente
para os testes (e não para sua função real).

21. Mock Object
• Gera resultados não determinísticos (hora, temperatura atual...);
• Tem estados que são difíceis de criar ou reproduzir (erro de
comunicação da rede);
• É lento (um banco de dados completo que precisa ser inicializado
antes do teste);
• Ainda não existe ou pode ter comportamento alterado;
• Teriam que adicionar informações e métodos exclusivamente
para os testes (e não para sua função real).

22. Mock Object
• Gera resultados não determinísticos (hora, temperatura atual...);
• Tem estados que são difíceis de criar ou reproduzir (erro de
comunicação da rede);
• É lento (um banco de dados completo que precisa ser inicializado
antes do teste);
• Ainda não existe ou pode ter comportamento alterado;
• Teriam que adicionar informações e métodos exclusivamente
para os testes (e não para sua função real).

23. Mock Object
• Gera resultados não determinísticos (hora, temperatura atual...);
• Tem estados que são difíceis de criar ou reproduzir (erro de
comunicação da rede);
• É lento (um banco de dados completo que precisa ser inicializado
antes do teste);
• Ainda não existe ou pode ter comportamento alterado;
• Teriam que adicionar informações e métodos exclusivamente
para os testes (e não para sua função real).

24. Alguns equívocos
• Escrever testes após o código de
produção
• TDD é sobre testes

25. Alguns equívocos
• Escrever testes após o código de
produção
• TDD é sobre testes

26. Por que utilizar TDD?
• Reduz o tempo com depuração;
• Incentiva a simplicidade;
• Aumenta a confiança no código;
• Provê uma documentação interna;
• Cria um design no sistema com
baixo acoplamento.

27. Por que utilizar TDD?
• Reduz o tempo com depuração;
• Incentiva a simplicidade;
• Aumenta a confiança no código;
• Provê uma documentação interna;
• Cria um design no sistema com
baixo acoplamento.

28. Por que utilizar TDD?
• Reduz o tempo com depuração;
• Incentiva a simplicidade;
• Aumenta a confiança no código;
• Provê uma documentação interna;
• Cria um design no sistema com
baixo acoplamento.

29. Por que utilizar TDD?
• Reduz o tempo com depuração;
• Incentiva a simplicidade;
• Aumenta a confiança no código;
• Provê uma documentação interna;
• Cria um design no sistema com
baixo acoplamento.

30. Por que utilizar TDD?
• Reduz o tempo com depuração;
• Incentiva a simplicidade;
• Aumenta a confiança no código;
• Provê uma documentação interna;
• Cria um design no sistema com
baixo acoplamento.

31. Eu não quero usar TDD por quê:
• “Vai demorar muito mais”
• “A funcionalidade é fácil, não precisa de
teste”
• “Não sei como testar” ou “Isso não dá para
testar”

32. Eu não quero usar TDD por quê:
• “Vai demorar muito mais”
• “A funcionalidade é fácil, não precisa de
teste”
• “Não sei como testar” ou “Isso não dá para
testar”

33. Eu não quero usar TDD por quê:
• “Vai demorar muito mais”
• “A funcionalidade é fácil, não precisa de
teste”
• “Não sei como testar” ou “Isso não dá para
testar”

34. Eu faço TDD. Preciso testar?
Mas é claro que SIM!

35. Organização da apresentação
1. A metodologia TDD
2. Construção de Casos de
Testes

36. E na prática,
como fica?

37. Um pequeno exemplo
Estamos desenvolvendo um software
para atender a uma loja. Um dos
requisitos é que o sistema não aceite
vendas parceladas para clientes que
tenham o nome sujo na praça, exceto
se um gerente da loja autorizar a
transação.

38. E agora?
Vamos precisar de uma classe de
validação de vendas! Como
desenvolvê-la?

39. Dividir para conquistar!

40. Uma venda parcelada para um
cliente com nome sujo deve ser
liberada caso haja autorização de um
gerente.

41. Uma venda parcelada para um
cliente com nome sujo não deve ser
liberada caso não haja permissão de
um gerente.

42. Uma venda parcelada para um
cliente com nome limpo deve ser
liberada sem solicitar permissão de
um gerente.

43. Uma venda não parcelada deve ser
liberada sem consultar o crédito e
sem solicitar permissão de um
gerente.

45. Obrigado!
Referências:
• Test-driven development: by example [Kent Beck]
• Growing Object-Oriented Software, Guided by Tests [Steve
Freeman]
Breno Martinusso Magno Machado
martinusso@gmail.com magnomp@gmail.com
breno.virtoo.com blog.magnomachado.com.br
@martinusso @magnomp