Testes é onde Claude Code se paga. Debug é onde ele fica esquisitamente impressionante.

Mas também é onde um workflow desleixado descarrila rápido. Deixe um agente "consertar" um teste do jeito errado e você sobe um CI verde com a feature quebrada. Deixe-o "depurar" um teste flaky e ele pode simplesmente apagar o teste.

Aqui estão os padrões que funcionam — e a regra que os mantém honestos.

A regra única

Operacionalize com dois sub-agentes que não podem ser o mesmo agente:

• test-writer — só adiciona ou modifica testes.
• test-fixer — só modifica código de produção para os testes passarem.

Se test-fixer algum dia quiser mexer num teste, tem que escalar para um humano. Esse é o contrato.

Padrão 1 — Delegação test-first

Para features novas, esse é o workflow mais limpo:

> /agents test-writer
> Objetivo: Escreva casos vitest para lib/cache.ts cobrindo:
>   - Despejo LRU com maxSize=3
>   - Expiração TTL sob fake timers
>   - get(missing) retorna undefined
> Restrições: vitest, fake timers via vi.useFakeTimers().
> DoD: Testes escritos, todos atualmente VERMELHOS.

A saída são testes falhando. Está certo.

> /agents test-fixer
> Faça os novos testes passarem sem modificar tests/cache.test.ts.

test-fixer implementa LRU + TTL em lib/cache.ts. Testes ficam verdes. Diff pequeno, focado, revisável.

Bem mais limpo do que "escreva o cache e os testes de uma vez" porque o autor dos testes é cego à implementação. Isso pega erros de API cedo.

Padrão 2 — Sussurrador de stack-traces

Quando algo explode em logs de prod, cole a stack trace. Claude Code é irracionalmente bom aqui.

> Leia essa stack trace e diga qual das três causas mais prováveis é a correta,
  com evidência arquivo:linha:

[cole a stack]

Depois proponha um fix de 5 linhas que trate APENAS dessa causa.

Duas notas:

• "Três causas mais prováveis" obriga a enumerar, não a se comprometer demais.
• "Fix de 5 linhas" limita o blast radius.

Acho que ~70% das sessões de debug "o que está acontecendo aqui?" terminam após essa única rodada.

Padrão 3 — Triagem de testes flaky

Testes flaky são a praga do CI. O agente é ótimo em classificá-los:

> Rode a suíte 10 vezes. Liste todo teste que:
>   - Falhou pelo menos uma vez e passou pelo menos uma vez.
>   - Mostre o erro exato do run que falhou.
> NÃO modifique código.

Você recebe uma tabela de triagem. Daí pergunta:

> Para o teste X (flaky), classifique a causa provável:
>   - Race condition
>   - Dependente de tempo (relógio real vs fake)
>   - Rede / dependência externa
>   - Vazamento de recurso de teste anterior
> Cite evidência arquivo:linha.

A classificação do agente raramente está 100% certa, mas quase sempre está "no bairro certo". Já dá para apontar a investigação na direção certa.

Padrão 4 — Bisect de regressão

Você tem git bisect e o agente tem git log. Combine:

> O endpoint /api/x retornava 200 semana passada e agora retorna 500.
> Encontre o commit culpado por:
>   1. git log --oneline desde o último deploy bom.
>   2. Para cada commit que mexe em /api/x ou seus imports, resuma a mudança em uma linha.
>   3. Identifique o suspeito mais provável e explique por quê.
>   4. NÃO execute código.

Mais rápido que um git bisect binário porque o agente lê os diffs no caminho. Melhor para codebases pequenas, com conjunto candidato de < 50 commits.

Padrão 5 — Cobertura como loop de coaching

Subestimado:

> Rode pnpm test --coverage em lib/auth/.
> Relate as linhas não cobertas.
> Para cada branch não coberta, proponha uma descrição de uma linha de um teste
> que a cobriria. NÃO escreva os testes.

Você recebe uma punch list. Daí o test-writer vai cobrindo um a um.

Por que é melhor que "atinja 90% de cobertura automaticamente": você vê a lista e pode despriorizar branches bobas (caminhos de erro impossíveis, defaults de switch exaustivo).

Coisas para nunca delegar em testes

• Decidir o que testar. Isso é conhecimento de produto.
• Decidir quando "bom o suficiente" é suficiente. Threshold de cobertura é decisão de valor.
• Marcar um teste como "skip" ou "todo". Sempre humano. Sempre.

O agente sugere; o humano decide o que conta como pronto.

Anti-padrões de debug que vejo toda semana

• "Só faça o teste passar." Catastrófico. Sempre. O reviewer pega; não pode pedir isso ao agente.
• "Adicione // @ts-ignore pra silenciar o build." O sub-agente deve recusar. Configure assim em .claude/agents/test-fixer.md:

# regras
- Nunca adicionar @ts-ignore, @ts-expect-error ou eslint-disable.
- Se não conseguir consertar um erro de tipo, escale.

• "Atualize o snapshot." Às vezes legítimo, mas o agente sempre deve mostrar o diff e explicar por que o snapshot mudou antes de atualizar.

O resultado depois de um trimestre

No codebase em que rodo isso há ~3 meses:

• Tempo médio pra triar um CI flaky: ~12 min → ~3 min.
• Tempo médio pra depurar uma stack trace de prod: ~20 min → ~5 min.
• Delta de cobertura em features novas: barulhento, mas +8 pontos percentuais em média.

Nenhum desses números é mágica do agente. São resultado de padronizar o workflow de testes com restrições que você não padronizaria facilmente com humanos.

---

Próximo artigo: Workflows de time — como times de engenharia estão integrando Claude Code hoje, do anti-padrão "uma licença só" ao padrão compartilhado .claude/ no git que escala.