Introdução a TDD

Test Driven DevelopmentDesenvolvimento Orientado por Testes

Daniel Capó Sobral

Teste é testeOu não?

Taxonomias• Funcional• Não

Funcional

Objeto de teste

• Automático

• Manual

Execução

• Caixa Preta

• Caixa Branca

• Caixa Cinza

Informação sobre o sistema

• Exploratório

• Pré-definido

Planejamento

• Teste Primeiro

• Teste por Último

Momento de escrita

• Qualitativo• Quantitativ

o

Resultado

• Estático (tipos, provas)

• Dinâmico

Execução do código testado

• Estado• Interação

Comportamento observado

• Verificação• Validação

Contratado vs Desejado

• TDD• ATDD• BDD

Técnica de Escrita

NíveisEscopo do Objeto Testado

Unit Testing

Integration Testing

System Testing

System Integration Testing

NíveisObjetivo do Teste

Beta

Alpha

Aceitação

Regressão

Smoke Test

Não funcionalPerformance Carga Usabilidade

SegurançaInternacionalizaç

ãoe Localização

Destrutivo

Compatibilidade Escalabilidade etc

Tá, mas e os testes de TDD?“In test-driven development a developer creates automated unit tests” – wikipedia

O que é TDD?

Técnica de Desenvolvimento

de Software

Teste Primeiro

Teste Unitário

Automatizado

TDD é sobre como escrever código de aplicação.

TDD não é sobre como escrever testes!

Porque não fazer TDD?

• Como escrever testes?• Como escrever código testável?• Como usar as ferramentas?• Como se faz TDD?

Curva de Aprendizado Íngreme:

• Mais linhas de código• Interrupções constantes

Menor Produtividade

• Mais código, mais manutenção• Mudanças de arquitetura quebram testes!• Mudanças de comportamento quebram testes!

Maior Custo de Manutenção

Porque fazer TDD?

• Confiança para efetuar mudanças• Testes resguardam contra regressão

Menor Custo de Manutenção

• YAGNI! (You Ain’t Gonna Need It!) significa menos desperdício

• Menos tempo corrigindo bugs: estava funcionando a cinco minutos atrás!

Maior Produtividade

• Mais testes leva a menos bugs• Testes unitários compreensivos resultam em baixo

acoplamento

Maior Qualidade

O que dizem os estudos?Maio

r Qualidade

?

• Inconclusivo• Boa correlação, mas...• Isolamento

• TDD ou outras práticas ágeis?• TDD ou número de testes?

• Mais testes levam a menos bugs? Confirmado.• Curva de aprendizado íngreme dificulta grupos de controle

E a Produtividade

?

• Inconclusivo• Conforme estudo, melhor, pior ou indiferente

Mas escrever um teste unitário parece simples...Famous last words.

Dificuldades

Onde começar?

O que testar?

O que não testar?

Quanto se testar de cada vez?

Que nome dar aos testes?

Como entender porque o

teste falhou?Como separar uma unidade de

suas dependência

s?

Fonte: Introducing BDD, Dan North

O que é um bom teste unitário?

Deve ser fácil de implementar.

Deve ser automatizável e reproduzível de forma confiável.

Qualquer um deve ser capaz de executá-lo, sem setups complicados.

Deve ser executável com um simples click.

Deve executar rapidamente.

Uma vez escrito, deve ser preservado para uso futuro.

Fonte: The Art of Unit Testing, Roy Osherove

Teste (automatizado) é Código

Em outras palavras, deve receber as mesmas atenções que o código da aplicação!

Atenção comManutenção Qualidade Legibilidade Refatoração Code Rot

Arcabouço, Armação, AndaimeAjuda a construir Removido ao fim da

construção

Mas software sem manutenção é software

morto!

Removendo dependências: Fakes

Stubs

Teste de estado

Mocks

Teste de Interação

Asserções

Espelhamento

Como?Injeção de Dependências

Ainda demora muito para chegar no TDD?

Três leis de TDD

Você não pode escrever código de aplicação mais do que o suficiente para fazer um teste

unitário passar.

Você não pode escrever código de teste mais do que o necessário para falhar; falhar compilação

também conta.

Você não pode escrever código de aplicação exceto para fazer passar um teste unitário.

Segundo Robert Martin

Três fases de TDDVermelho• Escrever

código de teste para evidenciar falha

Verde• Escrever

código de aplicação para corrigir falha

Azul• Refactoring

de código (aplicação e testes)

Fluxo de TDDEscrever teste

Escrever aplicação

Refatoração(aplicação e testes)

Falhou?

Passou?

Sim

Não

NãoSim

Executa teste

Executa teste

Passou?

Executa teste

Sim

NãoSim

Muito estranho! Como funciona isso na prática?

DemonstraçãoJogo de BolicheRegras:

10 jogadas (frames)1 ou 2 arremessos por jogada (1ª à 9ª)2 ou 3 arremessos na 10ª jogada10 pinos

1 ponto por pino derrubadoSpare – 10 pinos derrubados em 2 arremessos

10 pontos + próximo arremessoStrike – 10 pinos derrubados em 1 arremesso

10 pontos + 2 próximos arremessos

Diagrama de ClasseTODO

Escrevendo o código com TDDTODO

That’s all, folks!Discutir!

ReferênciasClean Coders (Robert Martin)Making Software: What Really Works, and

Why We Believe It (Andy Oram & Greg Wilson)

The Art of Unit Testing: with Examples in .Net (Roy Osherove)

Introducing BDD (Dan North)Wikipedia (duh!)Test Driven Development: By Example (Kent

Beck)