Claude Code Testes Automatizados: Fechando o Loop

Claude Code Testes Automatizados: Fechando o Loop

Claude Code produz código funcional mais rápido do que consigo ler. Por volta do meu terceiro projeto real com ele, notei que meu dia tinha se invertido: quase nenhum tempo digitando código, a maioria do tempo verificando que o que o agente construiu realmente faz o que pedi.

A solução é testes automatizados com Claude Code: dar ao agente permissão para rodar testes, fazê-lo escrever testes para tudo que constrói, e conectar hooks para os testes dispararem sem ninguém precisar lembrar de rodá-los. O agente pega seus próprios erros antes de você jamais vê-los, e a pilha de revisão encolhe para as coisas que genuinamente precisam de um humano.

Essa última parte é o ponto todo.

Por que testes viraram o gargalo

Verificação é agora o passo mais lento no desenvolvimento assistido por agente. Geração de código ficou barata; confiança que o código está correto não ficou. Se você usa um agente de código diariamente, seu gargalo já se moveu de "escrever a feature" para "provar que a feature funciona," quer você tenha nomeado isso ou não.

Já vi esse filme antes, em velocidade humana. Na Green Hat, antes de termos um pipeline, desenvolvedores faziam upload de arquivos direto para o servidor. As coisas eram sobrescritas, ambientes se misturavam, e todo deploy era um pequeno ato de fé. Construímos um pipeline prod/staging/dev adequado onde staging-para-prod exigia um pull request e uma aprovação, e erros de deployment caíram pela metade. Ninguém trabalhou mais duro. O caminho só parou de depender da memória de alguém.

Agentes de código recriam o mesmo problema exato dez vezes mais rápido. Um agente que edita quinze arquivos em vinte minutos e nunca roda um teste é um dev junior com acesso FTP para produção. A resposta é a mesma que era então: um gate determinístico que dispara toda vez, sem discipline nenhuma necessária.

O que testes automatizados com Claude Code realmente significa

Retire o buzz das palavras, e testes automatizados com Claude Code são duas peças mecânicas mais um hábito. As peças: o agente tem acesso suficiente para realmente executar sua suite de testes, e hooks em .claude/settings.json rodam esses testes automaticamente em eventos de ciclo de vida, alimentando falhas de volta no contexto do agente para que ele as corrija na mesma sessão. O hábito: instruir o agente a escrever e atualizar testes como parte de toda implementação, toda vez.

Nada disso é exótico. É a mentalidade usual de CI/CD aplicada dentro do loop do agente em vez de depois dele.

A parte de acesso vem primeiro, e é onde a maioria das setups quietamente falha. Se os testes precisam de um banco de dados, o agente precisa de um banco de dados. Se precisam de uma instalação WordPress, inicie wp-env ou uma stack Docker que o agente possa descartar e reconstruir. Um agente que não consegue executar o teste vai felizmente dizer que ele "passaria," o que não é muito útil. Escrevi sobre os trade-offs de permissão em mais profundidade em quando seu agente de IA tem as chaves para tudo, mas a versão curta é: escope o acesso a um ambiente descartável e seja generoso dentro dele.

A parte de prompt é uma frase que você reutilizará para sempre: "Escreva testes de integração para isso, rode-os, e não pare até passarem." Agentes são finalizadores preguiçosos. Deixado sozinho, Claude Code vai declarar vitória em "o código parece correto." A instrução explícita de continuar iterando até a suite estar verde muda a qualidade de saída mais que qualquer upgrade de modelo que tenha tentado.

Conectando hooks para que testes rodem sem ninguém pedir

Hooks são comandos shell que Claude Code executa em pontos fixos em seu ciclo de vida, e são a diferença entre "o agente usualmente testa" e "o agente sempre testa." A própria documentação da Anthropic os descreve como controle determinístico, que é uma forma educada de dizer: instruções em CLAUDE.md são puladas às vezes; hooks nunca são.

Dois eventos fazem a maioria do trabalho. PostToolUse dispara após toda edição de arquivo; aponte para uma verificação rápida e escopo como npx jest --findRelatedTests ou phpcs no arquivo alterado. Stop dispara quando o agente termina de responder; é aí que a suite completa pertence, porque rodar tudo após cada edição única vai moer a sessão até parar.

Uma setup mínima com sabor WordPress:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "phpcs --standard=WordPress \"$CLAUDE_FILE_PATH\" || true"
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          { "type": "command", "command": "vendor/bin/phpunit --testdox 2>&1 | tail -10" }
        ]
      }
    ]
  }
}

O || true no hook rápido importa: você quer que o agente veja a saída de falha, sem uma falha de formatador congelando a sessão toda. E o tail -10 mantém o resumo da suite curto o suficiente para informar o agente em vez de alagar seu contexto.

Um detalhe a mais que vale o seu lugar: hooks PreToolUse que retornam uma decisão deny bloqueiam a chamada de ferramenta mesmo quando você roda com --dangerously-skip-permissions. Então você pode dar ao agente autonomia ampla para velocidade e ainda bloquear concretamente os comandos que arruinariam sua semana. Essa combinação, via ampla mais paredes de concreto, é o que torna sessões longas e desassistidas viáveis de jeito nenhum. Emparelha naturalmente com a abordagem de skills Claude Code, onde procedimentos repetíveis param de viver em prompts e começam a viver em arquivos que o agente deve seguir.

O que muda em um projeto real

O efeito prático aparece em trabalho de manutenção, que é a maioria do trabalho. WP-AutoInsight roda em 3.000+ instalações ativas, e a coisa sobre um plugin nessa escala é que uma atualização descuidada gera tickets de suporte por dias. Quando o agente propõe uma mudança, hooks rodam PHPCS no arquivo tocado imediatamente, e a suite de testes quando termina. No momento em que olho para qualquer coisa, a falha óbvia já se foi. Minha revisão se torna o que uma revisão deveria ser: essa mudança faz sentido, ela lida com o caso extremo que os testes não pensaram?

Alguma verificação ainda precisa de um humano. Comportamento UI entre temas, qualquer coisa tocando fluxos de pagamento, email transacional, ações de admin que não vou dar credenciais de um agente para. Para esses, faço o agente fazer o prep em vez do trabalho: produzir uma checklist do que mudou, onde clicar, o que correto parece, e o que checar se não parecer, para que meu pass manual leve cinco minutos em vez de trinta. Mesmo princípio que a versão automatizada. Reduza o custo cognitivo de verificação até parar de ser o gargalo.

Isso também é, quietamente, a linha divisória entre setups de agente que sobrevivem contato com produção e os que demo bem e morrem. Escrevi sobre por que demos de IA falham em produção antes, e o padrão se repete aqui: a demo não tem loop de feedback de falha, produção exige um. Um agente com um harness de teste é um sistema. Um agente sem um é um estagiário muito confiante.

Onde começar

Não construa toda a aparelhagem no dia um. Adicione um único hook Stop que roda sua suite de testes existente e viva com ele por uma semana. Aí adicione a verificação rápida por edição. Aí os guardrails PreToolUse. Cada camada se paga antes de você adicionar a próxima, e se seu projeto não tem testes de jeito nenhum, o primeiro prompt é óbvio: faça Claude Code escreve-los. É genuinamente bom nisso, o que é uma espécie de poesia estranha.

Os agentes vão continuar ficando mais rápidos. O gap de verificação vai continuar ficando mais amplo para qualquer um que não fechar o loop.

Aonde seu tempo realmente vai quando você trabalha com um agente?

Se sua equipe adotou agentes de código e velocidade de shipping subiu enquanto confiança desceu, esse gap é um problema de processo, e problemas de processo são consertáveis. Desenhar harnesses de teste e guardrails ao redor de desenvolvimento assistido por IA é parte do consulting técnico que faço.