Claude Code para escrever testes: o que dá para delegar e o que você precisa conferir na mão

Fala aí, beleza? Existe uma coisa pior do que não ter teste nenhum: ter uma suíte inteira verdinha que não prova absolutamente nada

Você pediu, o agente entregou, o CI passou, e o bug foi pra produção do mesmo jeito

Se você já roda o agente em código de verdade, a pergunta deixou de ser "dá pra usar?"

A pergunta agora é outra: o que dá pra delegar sem dor de cabeça, e o que você TEM que conferir na mão

É isso que a gente separa aqui: a divisão de trabalho linha a linha, o fluxo passo a passo com os erros comuns de cada etapa, e a técnica que mostra se a suíte que o agente escreveu pega defeito ou só finge que pega 🙂

O que dá para delegar ao Claude Code e o que fica com você

A régua é simples: o agente é ótimo em PRODUZIR teste, e você continua sendo o único responsável pelo CRITÉRIO do teste

Produção é volume, estrutura, repetição

Critério é decidir o que aquele teste precisa provar, e isso não sai de prompt nenhum

Essa última linha é a que mais dói, e ela tem respaldo: um estudo de replicação de 2026 conclui que cobertura e mutation score de suítes geradas por LLM só valem como sinal confiável quando dá pra assumir que o código sob teste está correto

Se o código pode já estar quebrado e o objetivo do teste é justamente expor isso, as duas métricas deixam de ser indicador confiável (estudo completo no arXiv)

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que deixar pronto antes de pedir teste ao agente

Antes de abrir o prompt, três coisas precisam estar de pé

1. Regra fixa de teste no CLAUDE.md:

O Claude Code lê arquivos CLAUDE.md como memória do projeto

O escopo de usuário fica em ~/.claude/CLAUDE.md e o escopo de projeto fica em ./CLAUDE.md, na raiz do repositório

Os arquivos do diretório de trabalho e dos diretórios acima são lidos no início da sessão, e os CLAUDE.md de subpastas são carregados sob demanda, conforme a documentação oficial de memória

Ou seja: o que você escreve ali é a regra que o agente já entra sabendo, sem você repetir em todo prompt

Um bloco enxuto resolve (troque pelos valores do SEU projeto):

## Testes
- Framework de teste do projeto: <o que você usa>
- Comando único da suíte: <o comando que roda tudo>
- Política de mock: mock só na fronteira externa, nunca em módulo interno
- Não altere arquivos de teste já commitados

Repara que a política de mock entra aqui como REGRA, não como pedido solto no chat

2. Suíte rodando por um comando só:

Se rodar a suíte no seu projeto exige três comandos e uma variável de ambiente na mão, o agente não vai fechar o laço sozinho

Um comando único é o que transforma "escreveu teste" em "escreveu, rodou, viu falhar, corrigiu"

Se você ainda está montando essa base, vale ver antes o fluxo completo até o deploy pra ter o projeto redondo antes de meter agente em cima da suíte

3. Saber qual comportamento você quer provar:

Esse é o pré-requisito que ninguém escreve no checklist e é o mais importante

"Escreve testes pra esse arquivo" é um pedido sem critério, e o resultado costuma ser um monte de teste que executa código sem verificar nada

"Prova que quando o usuário está deslogado a função não devolve dado de outro usuário" é um pedido com critério

Passo a passo: o fluxo de teste com o Claude Code

O fluxo abaixo segue o padrão que a página oficial de boas práticas lista entre os workflows recomendados: write tests, commit; code, iterate, commit

A lógica por trás é a mesma do TDD de sempre: se o teste nunca falhou, você não sabe se ele testa alguma coisa

1. Escreva os testes primeiro e rode pra confirmar que eles falham. Esse é o passo que separa teste de decoração: um teste que já nasce verde, antes da implementação existir, é um teste que não olha pro código. Erro comum: pular a rodada de confirmação e ir direto pedir a implementação, aí você nunca vê o vermelho e perde a única prova de que a assertion morde

2. Commite os testes. Com os testes versionados, existe um contrato fixo que dá pra comparar depois. Erro comum: deixar teste e implementação no mesmo commit, o que apaga a fronteira entre "o que eu queria provar" e "o que o agente fez pra passar"

3. Peça a implementação instruindo o agente a NÃO modificar os testes. O doc oficial é explícito nisso: peça código que passe nos testes e diga pra ele não mexer nos testes. Erro comum: não dizer nada e depois descobrir que a assertion foi "ajustada" pra bater com o comportamento que saiu, o que inverte o sentido inteiro do exercício

4. Escope o prompt igual o doc exemplifica. O exemplo que está na própria documentação é curto e cirúrgico:

write a test for foo.py covering the edge case where the user is logged out. avoid mocks.

Repara nos três elementos: arquivo alvo, caso de borda específico e restrição de mock explícita. Erro comum: pedir "cobertura" em vez de pedir um comportamento, porque cobertura o agente entrega fácil e ela não garante nada

5. Separe papéis com o padrão Escritor/Revisor. O doc oficial descreve esse padrão com duas instâncias: uma escreve os testes, a outra escreve o código que precisa passar neles. Funciona porque a instância que implementa não tem no contexto o raciocínio de quem escreveu a assertion, então ela precisa satisfazer o contrato, não a própria narrativa. Erro comum: fazer tudo na mesma sessão e achar que é a mesma coisa

6. Fixe o papel em um subagente. Subagentes personalizados do Claude Code são arquivos Markdown com frontmatter YAML, cada um com system prompt, permissões de ferramenta e modelo próprios. Ficam em .claude/agents/ (nível projeto, versionado com o time) ou ~/.claude/agents/ (nível usuário, vale em todos os projetos), conforme a documentação oficial de subagentes

---
name: escritor-de-testes
description: Escreve testes a partir do comportamento descrito, sem mock de módulo interno
tools: Read, Grep, Glob, Write
---

Você escreve testes. Nunca escreve implementação.
Cada teste precisa ter assertion explícita sobre o comportamento pedido.
Se o comportamento não estiver claro, pergunte antes de escrever.

Aquele campo de permissões de ferramenta merece atenção de verdade, e não só por causa de teste: dar acesso amplo pro agente é decisão de segurança, e o vazamento no Claude Code é um bom lembrete de por que isso importa. Erro comum: criar o subagente e não versionar no projeto, aí a regra vale só na sua máquina e o time inteiro segue no improviso

7. Rode a suíte automaticamente com hook. O evento PostToolUse dispara depois que a chamada de ferramenta tem sucesso, e o matcher Edit|Write limita às ferramentas de edição de arquivo (guia de hooks)

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "<comando da sua suíte>"
          }
        ]
      }
    ]
  }
}

Dois detalhes que evitam surpresa: o timeout padrão é de 60 segundos e é configurável por hook, e hooks que casam com o mesmo evento rodam em paralelo. Erro comum: apontar o hook pra suíte inteira de um projeto grande e estourar o tempo a cada edição, quando o certo é apontar pro subconjunto rápido

Teste perpetuamente verde: como identificar e como prevenir

O sintoma:

A suíte está toda verde

Ela ficou verde na semana passada, ficou verde depois do refactor, ficou verde depois daquele bug que foi parar em produção

Esse é o cheiro clássico do teste perpetuamente verde: uma suíte que não acusa nada porque não é capaz de acusar nada

As causas:

Duas, principalmente

A primeira é assertion ausente: o teste chama a função, o código executa, ninguém verifica o resultado

A segunda é mock que desacopla o teste do código real: você não está testando a sua lógica, está testando o mock que você mesmo escreveu

Praticantes descrevem exatamente esse quadro: suíte que executa toda linha do código e mesmo assim deixa passar quase todo defeito que aparece depois

Cobertura ali virou métrica de execução, não de verificação

A solução, na prática:

Mutation testing

Que é isso? A técnica é injetar bug de propósito no código (trocar um > por >=, inverter um booleano, remover uma linha) e ver se a suíte quebra

Se você estragou o código e todo mundo continua verde, o teste não estava testando aquilo

A técnica está listada no Technology Radar da Thoughtworks como forma de avaliar a qualidade real da suíte

E dá pra fazer uma versão manual disso hoje, sem ferramenta nenhuma, logo depois que o agente entregar a suíte:

1. Escolha uma função crítica que os testes novos cobrem
2. Estrague ela de propósito: inverta a condição, troque o operador, apague a linha que faz o trabalho
3. Rode o comando único da suíte e olhe o resultado
4. Se ficou vermelho, ótimo, a assertion morde. Se continuou verde, aquele teste é decoração e volta pra fila
5. Desfaça a alteração e repita na próxima função que importa

É chato? É. Mas é o único jeito de sair do "passou no CI" e chegar em "a suíte pega defeito"

A prevenção:

Mais barata que o remédio, e são só duas regras

Rodar o teste ANTES da implementação existir, pra ver o vermelho

E não deixar o agente mexer nos testes depois de commitados

Um contexto honesto pra fechar: a própria Anthropic avalia formalmente a tendência dos seus modelos de burlar teste (reward hacking) em tarefas de código

O system card usa versões com hidden tests (testes fuzzados a partir dos testes visíveis ao modelo) e classificadores, e a taxa de hack é a fração de problemas em que a solução passa nos testes visíveis mas falha nos escondidos

Se o método de avaliação de quem faz o modelo é esconder teste, dá pra imaginar por que "passou na suíte" não é veredito final

Quando confiar mais no teste gerado (e quando desconfiar)

Cenário 1: regressão, com o código assumido correto

Aqui é onde o agente brilha

O comportamento atual é o comportamento desejado, e o que você quer é congelar isso pra saber quando alguém quebrar

Nesse cenário, o estudo de replicação de 2026 aponta que cobertura e mutation score funcionam como sinal

É trabalho de volume, estrutura repetida, muitos casos parecidos, exatamente o tipo de coisa que sai barata e rápida

Cenário 2: caça a bug, com o código possivelmente quebrado

Aqui a coisa vira

Se o código pode já estar com bug e o objetivo do teste é EXPOR esse bug, as duas métricas deixam de ser indicador confiável, segundo o mesmo estudo

Faz sentido quando você para pra pensar: teste gerado a partir do código existente tende a documentar o comportamento existente

Se o comportamento existente é o bug, você acabou de escrever um teste que protege o bug 😛

Nesse cenário, o comportamento esperado precisa vir de você, do ticket, da spec, da reprodução do usuário, nunca do arquivo que está sob suspeita

Como os times da Anthropic fazem internamente

A Anthropic publicou como os times dela usam o Claude Code, e dois relatos casam direto com essa divisão

O time de Security Engineering trocou o ciclo de "design doc, código porco, refatora, desiste dos testes" por pedir pseudocódigo, conduzir o agente em TDD e revisar de tempos em tempos

O time de Product Design usa o Claude Code para escrever testes de features novas, com comentários automatizados de Pull Request via GitHub Actions (relato completo no blog da Anthropic)

Nos dois casos tem a mesma pegada: o agente produz, o humano conduz e revisa em intervalo definido

O próximo passo

A régua que vale a pena levar daqui é uma frase só: delegue a PRODUÇÃO do teste, nunca delegue o CRITÉRIO do que o teste prova

O agente escreve rápido, cobre caso de borda que você listou, repete estrutura sem reclamar e itera até a suíte fechar

O que ele não faz é decidir o que precisa ser verdade no seu sistema

Três passos concretos pra sair da leitura e ir pro repo:

1. Escrever a política de teste no CLAUDE.md do projeto (framework, comando da suíte, política de mock, proibição de alterar teste commitado)
2. Rodar um ciclo TDD completo em uma feature pequena, com os testes commitados antes da implementação
3. Estragar uma função de propósito e rodar a suíte, do jeito manual que mostrei ali em cima, antes de confiar na cobertura

Sobre modelo: o Claude Opus 5 foi lançado em 24 de julho de 2026, é o Opus atual da Anthropic e o padrão no plano Claude Max, além de ser o modelo mais forte disponível no Claude Pro

Modelo melhor ajuda, claro, mas nenhum deles substitui você olhando a assertion e perguntando "isso aqui quebra se o código quebrar?"

Testa aí e me conta como foi, até o próximo post! =)