Tdd Development

Test-Driven Development (TDD)

Esta skill implementa a disciplina de Test-Driven Development. TDD não é opcional — é mandatório para código confiável e manutenível.

Regra Fundamental

Escreva o teste primeiro. Veja-o falhar. Escreva o código mínimo para passar.

Observar o teste falhar prova que o teste realmente valida algo significativo.

O Ciclo RED-GREEN-REFACTOR

1. RED - Teste Falha

┌─────────────────────────────────────────┐
│  1. Escreva um teste MÍNIMO que falha   │
│  2. Execute o teste                      │
│  3. CONFIRME que ele falha              │
│  4. O teste deve falhar pelo motivo     │
│     CORRETO (não por erro de sintaxe)   │
└─────────────────────────────────────────┘

2. GREEN - Teste Passa

┌─────────────────────────────────────────┐
│  1. Escreva o código MÍNIMO necessário  │
│  2. Não adicione funcionalidade extra   │
│  3. Execute o teste                      │
│  4. CONFIRME que ele passa              │
└─────────────────────────────────────────┘

3. REFACTOR - Melhore o Código

┌─────────────────────────────────────────┐
│  1. Melhore a qualidade do código       │
│  2. Remova duplicação                    │
│  3. Melhore nomes e estrutura           │
│  4. Execute os testes novamente         │
│  5. CONFIRME que ainda passam           │
└─────────────────────────────────────────┘

Regras Absolutas (NÃO NEGOCIÁVEIS)

O Que NUNCA Fazer

Racionalizações Comuns (e Por Que São Falsas)

"É só um código simples, não precisa de teste"

• FALSO: Código simples é o mais fácil de testar. Se não consegue testar, não é simples.

"Vou testar depois"

• FALSO: Testes escritos depois são testes de confirmação, não de design. Perdem o valor de TDD.

"Já testei manualmente"

• FALSO: Teste manual não é repetível, não documenta comportamento, não previne regressões.

"O prazo está apertado"

• FALSO: TDD é mais rápido no médio prazo. Bugs custam mais que testes.

"Já escrevi o código, seria desperdício deletar"

• FALSO: Sunk cost fallacy. Código sem teste é liability, não asset.

Checklist de Verificação

Antes de Escrever Código

• Existe um teste que falha para este comportamento?
• O teste falha pelo motivo correto?
• O teste é mínimo (testa uma coisa só)?
• O nome do teste descreve o comportamento esperado?

Depois de Escrever Código

• O teste passa agora?
• Você escreveu o código MÍNIMO necessário?
• Não adicionou funcionalidade "de brinde"?
• Todos os testes anteriores ainda passam?

Na Fase de Refactor

• O código está mais limpo?
• Removeu duplicação?
• Os nomes são claros?
• TODOS os testes ainda passam?

Padrões de Teste

Bom Teste

// ✅ CORRETO: Nome descritivo, uma asserção, arrange-act-assert
describe('Calculator', () => {
  it('should add two positive numbers', () => {
    // Arrange
    const calculator = new Calculator();

    // Act
    const result = calculator.add(2, 3);

    // Assert
    expect(result).toBe(5);
  });
});

Teste Problemático

// ❌ ERRADO: Múltiplas asserções, nome vago, sem estrutura clara
describe('Calculator', () => {
  it('works', () => {
    const calc = new Calculator();
    expect(calc.add(2, 3)).toBe(5);
    expect(calc.subtract(5, 3)).toBe(2);
    expect(calc.multiply(2, 3)).toBe(6);
    expect(calc.divide(6, 2)).toBe(3);
  });
});

Red Flags - Sinais de Violação TDD

Troubleshooting

Fluxo de Trabalho Recomendado

1. Receba um requisito
   ↓
2. Escreva um teste que falha (RED)
   ↓
3. Confirme a falha
   ↓
4. Escreva código mínimo (GREEN)
   ↓
5. Confirme que passa
   ↓
6. Refatore se necessário (REFACTOR)
   ↓
7. Confirme que ainda passa
   ↓
8. Repita para o próximo requisito

Ferramentas Recomendadas

JavaScript/TypeScript

• Jest
• Vitest
• Mocha + Chai

Python

• pytest
• unittest

Comandos Úteis

# Watch mode - executa testes automaticamente
npm test -- --watch

# Coverage - verifica cobertura
npm test -- --coverage

# Single file
npm test -- path/to/test.spec.ts

Lembre-se

"Código sem teste é código quebrado que ainda não descobrimos."

"TDD não é sobre testes. É sobre design. Os testes são um bônus."

"Se você não viu o teste falhar, você não sabe se ele funciona."

Esta skill deve ser ativada AUTOMATICAMENTE quando:

• O usuário pede para implementar uma feature
• O usuário pede para corrigir um bug
• O usuário pede para refatorar código
• O usuário menciona testes ou qualidade de código

Converted and distributed by TomeVault — claim your Tome and manage your conversions.