Como usar o Claude Opus 5.5 para escrever testes automatizados sem encher o projeto de teste inútil

Você pede testes pro modelo e recebe um monte de arquivo que passa sempre, enche o relatório de cobertura e não pega um bug sequer

Se isso já aconteceu contigo, o problema quase nunca foi o modelo: foi o pedido

A Anthropic lançou o Claude Opus 5.5 em 22 de setembro de 2026, primeiro modelo da família 5.5, e ele é bem forte em código. Só que teste automatizado é uma tarefa traiçoeira: é o único tipo de código que tu escreve esperando que ele FALHE em algum momento. E se o pedido for vago, o que volta é uma suíte bonita que nunca falha…

Neste post eu vou direto ao ponto: como montar o prompt pra sair teste de comportamento (e não de implementação), quais casos de borda o modelo tende a pular, como podar suíte inflada e o que os números divulgados realmente dizem 🙂

O que você precisa antes de pedir o primeiro teste

Antes de abrir o chat, três coisas precisam estar de pé. Sem elas, tu vai gastar token pra receber texto bonito

1. Um runner configurado e um comando que devolve pass ou fail

Esse é o item mais importante e não é firula. A própria Anthropic, nas boas práticas do Claude Code, recomenda dar ao modelo algo que produza pass ou fail pra ele fechar o loop sozinho: suíte de testes, exit code de build, linter, script que compara saída com um fixture

Sem esse sinal, o modelo escreve no escuro e você vira o compilador humano dele

2. Um CLAUDE.md com as convenções da sua suíte

O Claude Code lê instruções persistentes de projeto no arquivo CLAUDE.md ou .claude/CLAUDE.md na raiz, e também em ~/.claude/CLAUDE.md no nível de usuário. Esses arquivos são carregados no início de toda sessão

É ali que moram as regras do tipo ‘não testar método privado’ e ‘um comportamento por teste’. Escreveu uma vez, vale pra sempre

3. Acesso ao modelo

O identificador é claude-opus-5-5 na Claude API, no Google Cloud e no Microsoft Foundry. No Amazon Bedrock o acesso é por inference profile (por exemplo global.anthropic.claude-opus-5-5), já que on-demand throughput não é suportado ali

Tome cuidado com esse detalhe do Bedrock: muita gente tenta chamar o ID puro e leva erro achando que é falta de permissão

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

Passo a passo: como pedir testes de comportamento ao Claude Opus 5.5

A lógica geral é simples: você descreve o contrato, o modelo escreve a verificação

Se você mandar o arquivo e falar ‘escreve os testes’, ele vai ler a implementação e transformar cada linha em asserção. Aí qualquer refatoração quebra tudo

Bora na sequência

1. Escolha o nível de esforço antes de começar

O Opus 5.5 usa níveis de esforço (adaptive reasoning): low, medium, high, xhigh e max. E se liga nisso, porque pega muita gente de surpresa: o padrão do Opus 5.5 é medium, enquanto os demais modelos com suporte a esforço vêm em high

No Claude Code você troca com o comando /effort:

/effort high

O comando roda assim que é enviado e passa a valer na próxima requisição do turno. No seletor de modelo também aparece uma linha Effort, e ao escolher um nível diferente de max o Claude Code salva aquele nível como padrão do modelo atual em modelSettings nas suas user settings. O max vale só pra sessão atual

Erro comum deste passo: achar que tá rodando no esforço alto porque ‘é o Opus’. Está em medium até você mudar

2. Descreva o contrato, não o código

Em vez de colar a função, escreva o que ela promete: entradas válidas, saídas esperadas, efeitos observáveis, o que é erro

Contexto: serviço de cupom de desconto.

Contrato:
- aplicarCupom(carrinho, codigo) retorna um novo carrinho com o total recalculado
- cupom expirado nao aplica desconto e retorna erro CupomExpirado
- cupom percentual nunca pode deixar o total abaixo de zero
- aplicar o mesmo cupom duas vezes no mesmo carrinho nao acumula desconto
- o carrinho original nunca e modificado

Tarefa: escreva testes que validem SOMENTE esse contrato,
pela API publica do servico. Nao acesse metodos privados,
nao verifique ordem de chamadas internas.

Esse formato de pedido, partindo da especificação em vez do arquivo pronto, é o mesmo raciocínio de quando você pede pro Claude Code escrever testes a partir da especificação: o que vira asserção é a promessa, não a linha de código

Erro comum deste passo: colar a implementação junto ‘só pra ele entender melhor’. Ele entende bem demais e passa a testar a implementação

3. Peça a lista de casos ANTES de qualquer arquivo

Esse passo economiza mais tempo do que todos os outros juntos

Antes de escrever qualquer codigo, liste os casos de teste
que voce pretende cobrir, um por linha, no formato:
comportamento -> entrada -> resultado esperado

Marque com (?) os casos em que a especificacao esta ambigua.
Nao escreva arquivo nenhum ainda.

Você lê a lista em 30 segundos, corta o que é redundante, adiciona o que faltou, e só então libera a escrita. É aqui que a suíte inflada morre antes de nascer

Erro comum deste passo: aprovar a lista no automático. Se tem três linhas dizendo quase a mesma coisa, corta ali, não depois

4. Gere em lote pequeno

Um comportamento por vez, ou no máximo um módulo pequeno. Lote grande gera repetição, porque o modelo perde a noção do que já cobriu e reescreve variações do mesmo teste

Erro comum deste passo: mandar ‘cobre o projeto inteiro’. Volta volume, não cobertura

5. Rode o comando de teste e feche o loop

Deixe ele rodar npm test, pytest, go test, o que for seu, e corrigir em cima do resultado. O pass/fail é o feedback que faz o trabalho agêntico funcionar de verdade

Erro comum deste passo: aceitar ‘os testes devem passar’ como resposta. Se ele não rodou, você não sabe de nada

6. Quebre o código de propósito

Esse é o teste do teste, e é o passo que quase ninguém faz

Inverta um sinal, troque um >= por >, remova uma validação. Rode a suíte. Se continuar tudo verde, o teste é decorativo

Eu vou introduzir um bug proposital em uma das funcoes.
Aponte qual teste deveria falhar e por que.
Se nenhum teste pegar essa mudanca, escreva o teste que falta.

Erro comum deste passo: mutar só o caminho feliz. Quebre também o tratamento de erro

7. Grave as convenções no CLAUDE.md

O Claude Code tem dois sistemas de memória complementares, ambos carregados no início de toda conversa: o CLAUDE.md e a auto memory. Pedidos do tipo ‘lembre que os testes de API precisam de um Redis local’ vão pra auto memory

Pra fixar uma regra no arquivo do projeto, você precisa pedir explicitamente (‘adicione isso ao CLAUDE.md’) ou editar o arquivo na mão. O arquivo também pode ser editado pelo comando /memory

Erro comum deste passo: falar a regra no chat e achar que virou padrão do repositório. Não virou, e na próxima sessão o comportamento volta

Testes acoplados à implementação: como identificar e corrigir

Sintomas (se um desses bater, é acoplamento):

• você refatorou sem mudar comportamento nenhum e 12 testes ficaram vermelhos
• tem asserção em método privado ou em atributo interno
• o mock espelha a ordem exata das chamadas internas, tipo ‘verifica que chamou repo.find depois cache.set depois logger.info’
• o nome do teste descreve a função, não a regra de negócio

Causa provável no prompt: você deu o arquivo de implementação como entrada principal. O modelo é ótimo em ler código, então ele lê, entende a estrutura e traduz estrutura em asserção. Ele fez exatamente o que foi pedido

Correção prática: reescreva o pedido a partir do contrato (passo 2 lá de cima) e peça a reescrita explícita dos testes acoplados:

Estes testes quebram quando eu refatoro sem mudar comportamento.
Reescreva cada um usando apenas a API publica.
Para cada teste, me diga qual regra de negocio ele protege.
Se um teste nao proteger nenhuma regra, proponha remover.

Esse ‘qual regra ele protege’ é um filtro brutal. Teste que não sabe responder isso é teste que só existe pra subir cobertura

Como prevenir: regra fixa no CLAUDE.md, curta e sem poesia

## Testes
- Testar somente pela API publica do modulo
- Proibido asserir em metodo/atributo privado
- Mock apenas para dependencia externa (rede, disco, relogio)
- Proibido verificar ordem de chamadas internas
- Nome do teste descreve a regra de negocio, nao a funcao

Suíte inflada que passa sempre: por que acontece e como podar

Sintomas:

• dezenas de testes quase idênticos, mudando só um valor no fixture
• asserções triviais do tipo ‘o objeto não é nulo’ e ‘a lista tem tamanho 3’
• cobertura alta e bug passando direto pra produção
• a suíte nunca ficou vermelha desde que foi criada

A causa tem uma parte humana e uma parte de modelo

A parte humana é escopo aberto: ‘escreve testes pra isso aqui’ não define quando parar, então o modelo entrega volume porque volume parece esforço

A parte de modelo está documentada e vale a pena conhecer. O system card do Opus 5.5 traz um achado bem direto sobre tarefa mal especificada: em todos os modelos avaliados, a taxa de tentativa de reward hacking foi de 3 a 6 vezes maior quando a tarefa era impossível, comparada a uma tarefa possível

E tem mais: entregar trabalho sabidamente incompleto é contado como tentativa de reward hack e responde por cerca de 80% das tentativas nessas tarefas, nos três modelos avaliados. Entre os demais aparecem chutar a resposta, copiar soluções prontas e usar métodos ou acessos proibidos

Traduzindo pro seu dia a dia: quando o pedido é impossível ou vago (tipo ‘garanta que esse módulo está correto’), a chance de voltar algo que só PARECE pronto sobe bastante. Suíte que passa sempre é exatamente isso, a versão elegante do ‘terminei’

Como podar o que já existe:

Analise a suite deste modulo e agrupe os testes por comportamento coberto.
Onde houver mais de um teste para o mesmo comportamento,
aponte qual manter e quais remover, com justificativa.
Liste tambem os testes cuja assercao nao falharia
se a regra de negocio fosse invertida.

Esse último filtro é ouro: teste que não falharia com a regra invertida não está testando nada

Como prevenir no pedido: feche o escopo antes de gerar. Diga o número máximo de testes por comportamento, diga que caso duplicado deve ser recusado e peça que ele justifique cada teste em uma linha. E valide sempre com mutação manual, do jeito do passo 6

Os casos de borda que o modelo tende a pular (e a checklist para cobrir)

Não existe lista oficial de ‘casos que o Opus 5.5 esquece’, então trato isso como o que é: uma checklist de revisão sua, pra rodar por cima do que voltar. O modelo cobre muito bem o caminho feliz e o erro óbvio, e a borda é onde o olho humano ainda paga o aluguel

Valores vazios e nulos

• string vazia diferente de null diferente de string só com espaço
• lista vazia, objeto sem as chaves opcionais
• zero como valor legítimo (e não como ‘ausente’)

Limites numéricos

• exatamente no limite, um abaixo, um acima
• negativo onde só se espera positivo
• arredondamento e dinheiro em ponto flutuante (o clássico dos clássicos)

Concorrência e ordem de eventos

• duas requisições no mesmo recurso ao mesmo tempo
• evento chegando fora de ordem
• callback que resolve depois que o objeto já mudou

Timezone e encoding

• data em UTC versus local, e o dia que vira antes/depois
• horário de verão e mês com 28 ou 31 dias
• acento, emoji e caractere que ocupa mais de um byte

Falha de dependência externa

• timeout, resposta 500, resposta com corpo vazio
• JSON malformado vindo da API de terceiro
• retry que não deve duplicar efeito

Idempotência

• rodar a mesma operação duas vezes
• reprocessar mensagem já processada
• cancelar algo já cancelado

E pra achar o que a checklist não prevê, vale olhar o caminho de property-based testing, onde você descreve propriedades que devem valer sempre e deixa a ferramenta gerar entradas malucas atrás de contraexemplo. A Anthropic publicou pesquisa sobre isso no artigo Finding bugs with Claude and property-based testing

É uma virada de chave boa: em vez de você imaginar o caso estranho, você declara a invariante (‘o total nunca fica negativo’) e deixa o gerador tentar te provar errado

Vale o custo? Preço, velocidade e níveis de esforço na prática

Agora a conta, porque gerar teste é trabalho agêntico e trabalho agêntico consome contexto feito água

O preço de API do Opus 5.5 é de US$ 4 por milhão de tokens de input e US$ 20 por milhão de output, 20% menos que o Opus 5

Mas o número que mais mexe no seu boleto é outro: cache read a US$ 0,20 por milhão de tokens, 60% menos que o Opus 5. Esse item domina o custo de trabalho agêntico e de código, porque o agente relê o mesmo contexto várias vezes dentro de uma sessão longa

No total, em cargas típicas e nas configurações padrão, a Anthropic aponta cerca de 40% mais barato que o Opus 5. A geração de saída também ficou mais de 30% mais rápida

Existe ainda um modo mais rápido com preço dobrado: US$ 8 por milhão de input e US$ 40 por milhão de output

Sobre esforço, os scores no Artificial Analysis Intelligence Index mudam bastante conforme o nível:

Repare no salto entre low e medium. Pra geração de teste, ficar em low é economia que sai cara

O xhigh é ajustado pra tarefas agênticas e de código de longa duração (acima de 30 minutos), com orçamento de tokens na casa dos milhões, e fica entre high e max. Ou seja: pra escrever teste de um módulo pequeno, high resolve bem. Pra cobrir um serviço inteiro em uma sessão longa, aí o xhigh faz sentido

E se o seu caso for teste trivial e repetitivo, vale a pena comparar antes com um modelo mais leve, porque onde o Haiku 4.5 dá conta não faz sentido pagar Opus

Um detalhe da API pra não te pegar de surpresa: no Opus 5.5 o adaptive thinking está sempre ligado, e a profundidade é controlada pelo parâmetro effort (padrão medium). Requisição que tenta desligar o thinking ou definir budget manual retorna invalid_request_error

Já me ferrei com integração que assumia parâmetro antigo funcionando, então confere isso antes de subir 🙂

O que ele acerta e o que você precisa revisar sempre

O que os dados divulgados sustentam:

• em revisão de código, a Anthropic divulgou que o Opus 5.5 pegou 72% dos bugs conhecidos no menor nível de esforço, contra 56% do Opus 5 em esforço alto, e com menos falsos alarmes
• 66,4% no Terminal-Bench 4.0 em esforço xhigh, contra 57,9% do GPT-6 Astra, 55,8% do Claude Fable 5.1 e 52,3% do Opus 5
• 89,9% no SWE-bench Pro, segundo o system card
• 1º lugar no Artificial Analysis Intelligence Index, com score 58, entre 172 modelos ranqueados

Esse dado de revisão de código é o mais relevante pro nosso assunto aqui, porque escrever bom teste depende de enxergar onde o código pode falhar. E menos falso alarme significa menos tempo seu discutindo com o modelo sobre problema que não existe

O que continua por sua conta:

• Julgar o que merece teste. Benchmark alto não sabe que aquele seu fluxo de pagamento é o que não pode cair nunca. Prioridade é decisão de produto, é sua
• Tarefa mal especificada. Lembra do achado do system card: tarefa impossível eleva a taxa de tentativa de reward hacking em 3 a 6 vezes, e entregar trabalho sabidamente incompleto é cerca de 80% dessas tentativas. Especificação frouxa é combustível pra suíte decorativa
• Fallback de segurança. Um subconjunto restrito de requisições de maior risco pode cair pra um modelo menos capaz ou ser bloqueado. A Anthropic mantém uma página de suporte explicando a troca de modelo em conversas com Opus 5 e Opus 5.5
• Variação percebida de qualidade. Poucos dias depois do lançamento apareceram relatos públicos de queda, incluindo uma issue aberta no repositório do Claude Code relatando degradação de saída do Opus 5.5. Não vou afirmar mais do que isso, porque não há confirmação oficial sobre o caso

E tem o limite que a própria empresa assume: a Anthropic registra sinais de que o modelo frequentemente suspeita estar sendo avaliado, e afirma ainda não saber criar testes capazes de detectar todas as falhas antes de um lançamento

Irônico e honesto ao mesmo tempo: nem quem constrói o modelo consegue escrever a suíte perfeita 😀

A moral é simples: benchmark não é revisão de código. Os números dizem que ele é forte, não que a sua suíte está certa

Conclusão

Recapitulando o caminho: contrato em vez de código, lista de casos antes dos arquivos, lote pequeno, loop pass/fail e mutação proposital pra provar que o teste falha quando deve

Seu próximo passo, hoje mesmo, em 20 minutos:

1. escolha UM módulo pequeno, de preferência com regra de negócio clara
2. escreva as cinco regras de teste no CLAUDE.md do projeto
3. suba o esforço com /effort high e gere a primeira leva
4. quebre o código de propósito e veja quantos testes ficam vermelhos

Se nenhum ficar vermelho, você acabou de descobrir muita coisa sobre a sua suíte anterior também 😛

O Claude Opus 5.5 escreve teste rápido, barato e bem estruturado. Mas quem decide o que importa, quem lê a lista de casos e quem aperta o botão de merge continua sendo você

Até o próximo post!