MÓDULO 1.4

🔴 TDD com agente: RED-GREEN-REFACTOR

Force o ciclo vermelho-verde-refatorar com seu agente. Nunca mais código sem teste, nunca mais teste sem falha vista.

📋6 tópicos ⏱️~35 min 🎯Intermediário 📖Teoria + Prática
1

🔴 Escrever o teste antes — e realmente vê-lo falhar

A fase RED é obrigatória e frequentemente pulada. Um agente sem a skill TDD escreve o código e depois escreve testes que passam — mas nunca confirma se os testes teriam falhado sem o código. Isso cria uma falsa sensação de segurança: testes que sempre passam não testam nada.

O problema do teste que nunca falhou

  • Agente escreve código de produção primeiro
  • Agente escreve teste que verifica o código existente
  • Teste passa — mas o teste verifica o código, não o requisito
  • Se o código tiver um bug, o teste pode ainda passar

O protocolo RED correto

  1. 1.Agente escreve APENAS o teste (sem código de produção)
  2. 2.Executa o teste: deve falhar — e pelo motivo certo
  3. 3.Confirma que a mensagem de erro faz sentido para o requisito
  4. 4.Só então escreve o código de produção mínimo para passar
2

📐 YAGNI e DRY na prática com agentes

Agentes de IA tendem à super-engenharia por padrão. Quando escrevem código, frequentemente adicionam abstrações "que podem ser úteis mais tarde", generalizam casos que ainda não existem e criam hierarquias de classes onde uma função seria suficiente. YAGNI e DRY são os freios necessários.

YAGNI em prática

You Ain't Gonna Need It

  • • Código mínimo para o teste passar
  • • Sem abstrações para "casos futuros"
  • • Sem generalizações desnecessárias
  • • Próxima tarefa adiciona o que falta

DRY em prática

Don't Repeat Yourself

  • • Extrair duplicação real, não antecipada
  • • Só abstrair depois de 3+ repetições
  • • Duplicação é ok até o REFACTOR
  • • Clareza > abstração prematura

Instrução para o agente

Quando o agente propuser abstrações que vão além do teste atual, peça explicitamente: "Escreva apenas o código necessário para este teste passar. Sem abstrações antecipadas."

3

⚠️ Antipadrões de teste com agentes

Agentes cometem erros específicos ao escrever testes que são difíceis de identificar sem experiência. Conhecer esses antipadrões permite corrigi-los antes que contaminem o conjunto de testes e criem uma falsa sensação de cobertura.

Teste tautológico

O teste verifica o que o código faz, não o que deveria fazer. Ex: expect(add(1,2)).toBe(add(1,2)). Sempre passa, nunca falha, testa nada.

Mock excessivo

Mockar tanto que o teste verifica apenas se o mock foi chamado, não se o comportamento real é correto. O teste passa mesmo se a lógica estiver completamente errada.

Teste de implementação

Verificar detalhes de implementação (que variáveis existem, que métodos foram chamados internamente) em vez de comportamento observável. Quebra a qualquer refatoração.

Teste sem asserção significativa

expect(true).toBe(true) ao final de uma função que pode lançar exceção. Verifica apenas que não explodiu, não que produziu o resultado correto.

4

💚 O ciclo de commit por RED-GREEN

A disciplina de commitar ao final de cada ciclo RED-GREEN completo cria um histórico granular que serve como rede de segurança. Se algo quebrar na tarefa 7, você tem um ponto de retorno na tarefa 6 com todos os testes passando — sem precisar desfazer horas de trabalho.

Anatomia de um commit TDD

# Mensagem de commit por ciclo

test: add validateEmail() — RED

feat: implement validateEmail() — GREEN

refactor: extract regex to constant — REFACTOR

O histórico que o TDD cria

Com commits por ciclo, você pode ver exatamente quando cada comportamento foi adicionado, qual teste o motivou e qual refatoração aconteceu. É um histórico narrativo do desenvolvimento, não apenas uma lista de mudanças.

5

♻️ Refatorar sem quebrar testes

A fase REFACTOR só começa depois que todos os testes estão verdes. Nela, você melhora a estrutura do código — extrai funções, remove duplicação, melhora nomes — garantindo que nenhum teste quebre durante o processo. Cada passo de refatoração é imediatamente verificado.

O que refatorar

  • • Extrair funções com nomes claros
  • • Remover duplicação real
  • • Melhorar nomes de variáveis
  • • Simplificar condicionais complexas
  • • Aplicar DRY onde surgiu duplicação

O que NÃO fazer no refactor

  • • Adicionar nova funcionalidade
  • • Mudar comportamento externo
  • • Fazer grandes mudanças estruturais
  • • Continuar se um teste quebrou
  • • Commitar com teste vermelho

Regra de ouro

Se um teste quebrou durante o refactor, desfaça o último passo imediatamente. Não tente consertar o teste — o refactor é que saiu do trilho. Volte ao verde antes de continuar.

6

🛠️ Prática: feature do zero em ciclo TDD completo

Use o plano do módulo anterior. Para cada tarefa, execute o ciclo completo RED-GREEN-REFACTOR com o agente. O exercício termina quando todas as tarefas do plano foram implementadas com testes passando e commits por ciclo.

Roteiro de cada ciclo

  1. REDPeça o teste da tarefa atual. Execute. Confirme que falha pelo motivo certo.
  2. GREENPeça o código mínimo. Execute os testes. Confirme que todos passam.
  3. REFACTORIdentifique o que melhorar. Refatore em pequenos passos, verificando testes a cada passo.
  4. COMMITCommit com mensagem clara. Avance para a próxima tarefa.

Critério de conclusão

Todas as tarefas do plano implementadas, todos os testes passando, histórico de commits com pelo menos um commit por ciclo. Sem código não coberto por teste.

Resumo do Módulo 1.4

Entendi por que o RED é obrigatório e como confirmar a falha correta
Sei aplicar YAGNI e DRY para resistir à super-engenharia do agente
Identifico os 4 antipadrões de teste mais comuns em agentes
Pratico o ciclo de commit por RED-GREEN para histórico granular
Sei fazer REFACTOR sem quebrar testes, em pequenos passos
Completei o exercício com feature implementada em TDD completo
Próximo módulo: 1.5 — Execução: subagentes e planos