Desenvolvimento Orientado a Testes

O Desenvolvimento Orientado a Testes é simples de descrever e difícil de dominar:

1. Vermelho: Escreva um teste que falha para o próximo pequeno pedaço de funcionalidade
2. Verde: Escreva o código mínimo para fazer o teste passar
3. Refatorar: Limpe o código mantendo os testes verdes

É isso. Três passos, repetidos centenas de vezes por dia.

A ordem importa. Você escreve o teste primeiro, antes que qualquer código de produção exista. Isso parece estranho no início. Mas muda tudo:

• Você pensa sobre como o código será usado antes de como será implementado
• Você obtém feedback imediato sobre se seu código funciona
• Você constrói uma rede de segurança que permite mudanças sem medo
• Você cria documentação executável do que o código faz

A parte mais difícil do TDD é aprender a escrever testes para código que ainda não existe. Veja como:

Comece com a interface, não com a implementação. Como o código deveria ser quando estiver pronto? Escreva um teste que o use dessa forma.

Comece pequeno. Não tente testar tudo de uma vez. Teste o caso mais simples possível primeiro.

Faça-o falhar pelo motivo certo. O teste deve falhar porque a funcionalidade não existe, não porque você cometeu um erro de sintaxe.

Use nomes de teste como documentação. O nome do teste deve descrever qual comportamento você está testando: "retorna lista vazia quando nenhum item corresponde ao filtro" e não "teste1."

Escrever o teste primeiro força você a pensar sobre:

• Quais entradas este código precisa?
• Quais saídas ele deve produzir?
• O que acontece em casos extremos?
• Como outro código vai chamar isso?

Essas são questões de design. Ao respondê-las antes de escrever o código, você toma melhores decisões de design.

Depois de ter um teste que falha, faça-o passar. Mas aqui está a disciplina: escreva o código mínimo para passar no teste, nada mais.

Isso significa:

• Se uma constante faz o teste passar, use uma constante
• Se codificar um valor de retorno funciona, codifique-o
• Não generalize até ter testes que exijam generalização

Isso parece ridículo. "Apenas retornar 5?" Sim, se isso faz o teste passar. Então escreva outro teste que force você a fazer computação real.

Por quê? Porque:

• Você constrói funcionalidade em passos pequenos e verificados
• Você nunca escreve código que não precisa
• Você descobre o design incrementalmente
• Cada linha de código é justificada por um teste

A mágica acontece quando você triangula. Primeiro teste: retorne 5. Segundo teste (entrada diferente): agora você tem que computar. Terceiro teste: agora você tem que lidar com casos extremos. Cada teste empurra você em direção a uma implementação real.

Depois que o teste passa, limpe. Isso não é opcional.

O passo de refatoração é onde você:

• Remove duplicação (DRY: Don't Repeat Yourself)
• Melhora nomes (faça o código ler como prosa)
• Simplifica lógica (reduz carga cognitiva)
• Reorganiza (move código para onde ele pertence)

A chave: mantenha os testes passando durante todo o processo. Refatore em passos pequenos, executando testes após cada mudança. Se os testes falharem, você sabe exatamente o que quebrou.

É aqui que o TDD compensa. Sem testes, refatorar é aterrorizante—você pode quebrar algo. Com testes, refatorar é rotina—você saberá imediatamente se quebrar algo.

Pular o passo de refatoração leva ao que Kent Beck chama de "desculpas verdes rápidas." O código funciona, mas está bagunçado. A bagunça se acumula. Logo a base de código fica difícil de trabalhar, e você perdeu o benefício do TDD.

Mito: TDD é mais lento. Realidade: TDD parece mais lento no início porque você está escrevendo mais código. Mas você gasta menos tempo depurando, menos tempo no debugger, menos tempo corrigindo bugs de produção. Ao longo da vida da base de código, TDD é mais rápido.

Mito: TDD leva a testes excessivos. Realidade: TDD leva exatamente aos testes que você precisa—nem mais, nem menos. Você testa o que constrói. Teste depois frequentemente leva a testes faltando (você esquece casos extremos) ou testes redundantes (você testa a mesma coisa de várias formas).

Mito: TDD não funciona para [meu domínio]. Realidade: TDD funciona para qualquer código que possa ser testado. Se seu código não pode ser testado, isso é um problema de design. TDD força você a escrever código testável, que é código melhor.

Mito: Não temos tempo para TDD. Realidade: Você não tem tempo para não fazer. Bugs são caros. Depuração é cara. Incidentes de produção são caros. TDD é um investimento que compensa.