Desenvolvimento Orientado por Testes (TDD)
TDD é o ciclo vermelho → verde. Esta skill é a referência que faz com que esse ciclo produza testes que valem a pena ser mantidos: o que é um bom teste, onde os testes vão, os anti-padrões e as regras do ciclo. Cada seção se aplica em cada ciclo: consulte-as antes e durante o ciclo, não depois.
Ao explorar a base de código, leia GLOSSARY.md (se existir) para que os nomes de teste e o vocabulário da interface correspondam à linguagem de domínio do projeto, e respeite os ADRs na área que você está mexendo.
O que é um bom teste
Testes verificam comportamento através de interfaces públicas, não de detalhes de implementação. O código pode mudar completamente; os testes não deveriam. Um bom teste lê como uma especificação: "usuário pode finalizar compra com carrinho válido" diz exatamente qual capacidade existe e sobrevive a refatorações porque não se importa com a estrutura interna.
Veja tests.md para exemplos e mocking.md para diretrizes de mocking.
Costuras (Seams): onde os testes vão
Uma costura (seam) é o limite público onde você testa: a interface onde você observa o comportamento sem acessar o interior. Testes vivem nas costuras, nunca contra partes internas.
Teste apenas nas costuras pré-acordadas. Antes de escrever qualquer teste, escreva as costuras sob teste e confirme-as com o usuário. Nenhum teste é escrito em uma costura não confirmada. Você não pode testar tudo; concordar as costuras de antemão é como o esforço de teste chega aos caminhos críticos e à lógica complexa, em vez de a cada caso extremo.
Pergunte: "Qual é a interface pública, e quais costuras devemos testar?" Dê a cada costura proposta uma nota de uma linha sobre o que ela captura e o que ela perde.
Quando a forma dessa interface estiver em questão (quão profundo é o módulo, onde a costura pertence, o que a interface deve expor), chame a ferramenta Skill com "codebase-design" para o vocabulário. É a fonte compartilhada dos termos módulo, interface, profundidade, costura, adaptador, alavancagem e localidade, e é uma referência para consultar, não uma sessão para executar.
Anti-padrões
- Acoplado à implementação: cria mocks de colaboradores internos, testa métodos privados ou verifica através de um canal lateral (consultando o banco de dados em vez de usar a interface). O sinal: o teste quebra quando você refatora, mas o comportamento não mudou.
- Tautológico: a asserção recalcula o valor esperado da mesma forma que o código faz (
expect(add(a, b)).toBe(a + b), um snapshot derivado manualmente da mesma forma, uma constante afirmada como igual a si mesma), portanto passa por construção e nunca pode discordar do código. Os valores esperados devem vir de uma fonte independente de verdade: um literal sabidamente correto, um exemplo trabalhado, a especificação. - Fatiamento horizontal: escrever todos os testes primeiro, depois toda a implementação. Testes em massa verificam comportamento imaginado: você testa a forma das coisas em vez do comportamento voltado ao usuário, os testes ficam insensíveis a mudanças reais, e você se compromete com a estrutura do teste antes de entender a implementação. Trabalhe em fatias verticais em vez disso: um teste → uma implementação → repita, cada um teste uma bala traçadora que responde ao que o último ciclo te ensinou.
Regras do ciclo
- Vermelho antes do verde. Escreva o teste com falha primeiro, depois apenas código suficiente para passá-lo. Não antecipe testes futuros nem adicione funcionalidades especulativas.
- Uma fatia de cada vez. Uma costura, um teste, uma implementação mínima por ciclo.
- Refatoração não faz parte do ciclo. Ela pertence à etapa de revisão (veja a skill
code-review), não ao ciclo de implementação vermelho → verde.