Desenvolvimento Orientado por Testes
Filosofia
Princípio central: Testes devem verificar o comportamento por meio de interfaces públicas, não detalhes de implementação. O código pode mudar completamente; os testes não devem.
Bons testes são do tipo integração: eles exercitam caminhos de código reais por meio de APIs públicas. Eles descrevem o que o sistema faz, não como o faz. Um bom teste lê-se 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 estão acoplados à implementação. Eles simulam colaboradores internos, testam métodos privados ou verificam por meios externos (como consultar um 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.
Consulte tests.md para exemplos e mocking.md para diretrizes sobre simulação.
Antipadrã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 real
- Você acaba testando a forma das coisas (estruturas de dados, assinaturas de funções) em vez do comportamento voltado ao usuário
- Os testes tornam-se insensíveis a mudanças reais — passam quando o comportamento quebra, falham quando o comportamento está bem
- Você ultrapassa seus próprios limites, comprometendo-se com a estrutura dos testes antes de entender a implementação
Abordagem correta: Fatias verticais por meio de tracer bullets. 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: test1, test2, test3, test4, test5
VERDE: impl1, impl2, impl3, impl4, impl5
CERTO (vertical):
VERMELHO→VERDE: test1→impl1
VERMELHO→VERDE: test2→impl2
VERMELHO→VERDE: test3→impl3
...
Fluxo de Trabalho
1. Planejamento
Ao explorar o código-fonte, use o glossário de domínio do projeto para que os nomes dos testes e o vocabulário da interface correspondam à linguagem do projeto, e respeite os ADRs na área que você está manipulando.
Antes de escrever qualquer código:
- Confirme com o usuário quais mudanças na interface são necessárias
- Confirme com o usuário quais comportamentos testar (priorize)
- Identifique oportunidades para módulos profundos (interface pequena, implementação profunda)
- Projete interfaces visando testabilidade
- Liste os comportamentos a testar (não etapas de implementação)
- Obtenha aprovação do usuário sobre o 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 são mais relevantes. Concentre o esforço de teste em caminhos críticos e lógica complexa, não em todos os casos de borda possíveis.
2. Tracer Bullet
Escreva UM teste que confirme UMA coisa sobre o sistema:
VERMELHO: Escreva teste para o primeiro comportamento → teste falha
VERDE: Escreva código mínimo para passar → teste passa
Este é seu tracer bullet — prova que o caminho funciona de ponta a ponta.
3. Loop Incremental
Para cada comportamento restante:
VERMELHO: Escreva o 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 antecipe testes futuros
- Mantenha os testes focados no comportamento observável
4. Refatoração
Depois que todos os testes passarem, procure por candidatos a refatoração:
- Extraia duplicação
- Aprofunde módulos (mova complexidade para trás de interfaces simples)
- Aplique princípios SOLID onde for natural
- Considere o que o novo código revela sobre o código existente
- Execute testes após cada etapa de refatoração
Nunca refatore enquanto VERMELHO. Chegue ao VERDE primeiro.
Checklist por Ciclo
[ ] O teste descreve comportamento, não implementação
[ ] O teste usa apenas a interface pública
[ ] O teste sobreviveria a uma refatoração interna
[ ] O código é mínimo para este teste
[ ] Nenhum recurso especulativo adicionado