Desenvolvimento Orientado a Testes
Filosofia
Princípio central: Testes devem verificar o comportamento através de interfaces públicas, não detalhes de implementação. O código pode mudar completamente; os testes não deveriam.
Bons testes são do tipo integração: eles exercitam caminhos de código reais através de APIs públicas. Eles descrevem o que o sistema faz, não como faz. Um bom teste lê como uma especificação — "usuário pode finalizar compra com carrinho válido" diz exatamente qual capacidade existe. Esses testes sobrevivem a refatorações porque não se importam com a estrutura interna.
Testes ruins são acoplados à implementação. Eles simulam colaboradores internos, testam métodos privados ou verificam por meios externos (como consultar o banco de dados diretamente em vez de usar a interface). O sinal de alerta: seu teste quebra quando você refatora, mas o comportamento não mudou. Se você renomear uma função interna e os testes falharem, esses testes estavam testando implementação, não comportamento.
Veja tests.md para exemplos e mocking.md para diretrizes de simulação.
Anti-Padrão: Fatias Horizontais
NÃO escreva todos os testes primeiro, depois toda a implementação. Isso é "fatiamento horizontal" — tratar VERMELHO como "escrever todos os testes" e VERDE como "escrever todo o código."
Isso produz testes ruins:
- Testes escritos em lote testam comportamento imaginado, não comportamento real
- Você acaba testando a forma das coisas (estruturas de dados, assinaturas de funções) em vez do comportamento voltado ao usuário
- Testes se tornam insensíveis a mudanças reais — passam quando o comportamento quebra, falham quando o comportamento está bom
- Você ultrapassa seus limites, comprometendo-se com a estrutura de teste antes de entender a implementação
Abordagem correta: Fatias verticais via balas traçadoras. Um teste → uma implementação → repetir. Cada teste responde ao que você aprendeu no ciclo anterior. Como você acabou de escrever o código, sabe exatamente qual comportamento importa e como verificá-lo.
ERRADO (horizontal):
VERMELHO: teste1, teste2, teste3, teste4, teste5
VERDE: impl1, impl2, impl3, impl4, impl5
CERTO (vertical):
VERMELHO→VERDE: teste1→impl1
VERMELHO→VERDE: teste2→impl2
VERMELHO→VERDE: teste3→impl3
...
Fluxo de Trabalho
1. Planejamento
Antes de escrever qualquer código:
- Confirmar com o usuário quais mudanças na interface são necessárias
- Confirmar com o usuário quais comportamentos testar (priorizar)
- Identificar oportunidades para módulos profundos (interface pequena, implementação profunda)
- Projetar interfaces para testabilidade
- Listar os comportamentos a testar (não passos de implementação)
- Obter aprovação do usuário no plano
Pergunte: "Como deve ser a interface pública? Quais comportamentos são mais importantes de testar?"
Você não pode testar tudo. Confirme com o usuário exatamente quais comportamentos importam mais. Concentre o esforço de teste nos caminhos críticos e na lógica complexa, não em todos os casos de borda possíveis.
2. Bala Traçadora
Escreva UM teste que confirme UMA coisa sobre o sistema:
VERMELHO: Escrever teste para o primeiro comportamento → teste falha
VERDE: Escrever código mínimo para passar → teste passa
Esta é sua bala traçadora — prova que o caminho funciona de ponta a ponta.
3. Ciclo Incremental
Para cada comportamento restante:
VERMELHO: Escrever próximo teste → falha
VERDE: Código mínimo para passar → passa
Regras:
- Um teste de cada vez
- Apenas código suficiente para passar no teste atual
- Não antecipar testes futuros
- Manter testes focados no comportamento observável
4. Refatorar
Depois que todos os testes passarem, procure por candidatos a refatoração:
- Extrair duplicação
- Aprofundar módulos (mover complexidade para trás de interfaces simples)
- Aplicar princípios SOLID onde natural
- Considerar o que o novo código revela sobre o código existente
- Executar testes após cada passo de refatoração
Nunca refatore enquanto estiver no VERMELHO. Vá para VERDE primeiro.
Checklist Por Ciclo
[ ] Teste descreve comportamento, não implementação
[ ] Teste usa apenas interface pública
[ ] Teste sobreviveria a uma refatoração interna
[ ] Código é mínimo para este teste
[ ] Nenhum recurso especulativo adicionado