introdução ao tdd
DESCRIPTION
Uma introdução ao Desenvolvimento Guiado por TestesTRANSCRIPT
Introdução ao TDD
Desenvolvimento Guiado por Testes
Breno Martinusso [email protected] breno.virtoo.com @martinusso
Magno Machado [email protected]
blog.magnomachado.com.br @magnomp
Palestrantes:
Organização da apresentação
1. A metodologia TDD
2. Construção de Casos de
Testes
O que é TDD?
“TDD = Test-First + Design Incremental” Kent Beck
Test-first
Escrever testes antes da implementação:
• Faz você pensar no comportamento • Reduz código especulativo • Documenta
Test-first
Escrever testes antes da implementação:
• Faz você pensar no comportamento • Reduz código especulativo • Documenta
Test-first
Escrever testes antes da implementação:
• Faz você pensar no comportamento • Reduz código especulativo • Documenta
Test-first
Escrever testes antes da implementação:
• Faz você pensar no comportamento • Reduz código especulativo • Documenta
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
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
Mantra do TDD
RED
GREEN
REFACTOR
RED
Escreva um teste que falhe
GREEN
Faça o teste passar
REFACTOR
Refatore
As 3 leis
Propostas por Robert C. Martin, também conhecido como Uncle Bob.
Primeira lei
Antes de escrever qualquer código de
produção, você deve escrever um
teste unitário que falha.
Segunda lei
Você deve parar de escrever o teste unitário
assim que ele falhar. Não compilar é uma falha.
Terceira lei
Você deve parar de escrever código de
produção assim que os testes falhos passarem.
Mock Object
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).
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).
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).
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).
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).
Alguns equívocos
• Escrever testes após o código de
produção
• TDD é sobre testes
Alguns equívocos
• Escrever testes após o código de
produção
• TDD é sobre testes
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.
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.
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.
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.
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.
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”
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”
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”
Eu faço TDD. Preciso testar?
Mas é claro que SIM!
Organização da apresentação
1. A metodologia TDD
2. Construção de Casos de
Testes
E na prática,
como fica?
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.
E agora?
Vamos precisar de uma classe de
validação de vendas! Como desenvolvê-la?
Dividir para conquistar!
Uma venda parcelada para um cliente com nome sujo deve ser
liberada caso haja autorização de um gerente.
Uma venda parcelada para um cliente com nome sujo não deve ser
liberada caso não haja permissão de um gerente.
Uma venda parcelada para um cliente com nome limpo deve ser
liberada sem solicitar permissão de um gerente.
Uma venda não parcelada deve ser liberada sem consultar o crédito e
sem solicitar permissão de um gerente.
Obrigado!
Referências:
• Test-driven development: by example [Kent Beck]
• Growing Object-Oriented Software, Guided by Tests [Steve
Freeman]
Breno Martinusso [email protected] breno.virtoo.com @martinusso
Magno Machado [email protected]
blog.magnomachado.com.br @magnomp