| name | tdd |
| description | Test-Driven Development — ciclo RED-GREEN-REFACTOR estrito. |
| argument-hint | <funcionalidade a implementar> |
| user-invocable | true |
| allowed-tools | Read, Edit, Write, Grep, Glob, Bash, Agent |
| model | sonnet |
| effort | high |
| context | fork |
TDD — Test-Driven Development
Implemente usando TDD estrito: $ARGUMENTS
Ciclo RED → GREEN → REFACTOR
🔴 RED — Escreva o teste PRIMEIRO
- Entenda o comportamento esperado
- Escreva UM teste que descreva esse comportamento
- Execute o teste — DEVE FALHAR
- Se o teste passar sem implementação → o teste está errado
npm test -- --run [arquivo]
REGRA: Nunca prossiga para GREEN se o teste não falhou primeiro.
🟢 GREEN — Implementação mínima
- Escreva o MÍNIMO de código para o teste passar
- Não otimize, não embeleze, não generalize
- Execute o teste — DEVE PASSAR
- Se não passar → corrija a implementação (não o teste)
REGRA: O fix mínimo. Se o teste espera return 42, retorne 42 literal.
🔵 REFACTOR — Melhore sem mudar comportamento
- Todos os testes passando? Pode refatorar
- Melhore: naming, duplicação, estrutura
- Execute os testes novamente — DEVEM continuar passando
- Se algum teste quebrou → desfaça o refactor
REGRA: Refactor só com todos os testes verdes.
Protocolo
1 teste por vez
Não escreva 5 testes e depois implemente tudo. O ciclo é:
1 teste RED → 1 implementação GREEN → refactor → próximo teste
Naming de testes
Descreva o comportamento, não o método:
- ✅
should return 404 when user not found
- ✅
should calculate total with discount applied
- ❌
test_get_user
- ❌
testCalculate
Cobertura de cenários (ordem)
- Happy path — o caso mais comum
- Edge cases — null, vazio, limites, zero
- Erros — exceções, timeouts, inputs inválidos
- Concorrência — race conditions (se aplicável)
Anti-padrões (PROIBIDO)
| Anti-padrão | Correto |
|---|
| Escrever implementação antes do teste | Teste primeiro, sempre |
| Teste que nunca falha (tautologia) | Teste deve ser falsificável |
| Múltiplos testes antes de implementar | 1 teste por vez |
| Refatorar com testes falhando | Verde antes de refatorar |
| Testar implementação interna | Testar comportamento observável |
Quando usar
- Feature nova que precisa de cobertura garantida
- Bug fix (escreva teste que reproduz o bug → fix → verde)
- Lógica complexa onde edge cases importam