introdução ao tdd

Introdução ao TDD

Desenvolvimento Guiado por Testes

Breno Martinusso martinusso@gmail.com breno.virtoo.com @martinusso

Magno Machado magnomp@gmail.com

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 martinusso@gmail.com breno.virtoo.com @martinusso

Magno Machado magnomp@gmail.com

blog.magnomachado.com.br @magnomp