Como Verificar Código Gerado por IA Antes de Fazer o Merge

O problema de revisar código que você não escreveu

Um agente de codificação de IA pode produzir uma funcionalidade funcional em minutos. O gargalo mudou de lugar: a restrição não é mais a velocidade com que o código é escrito, é a confiança com que alguém pode afirmar que o código faz o que deveria fazer. Ler cuidadosamente um diff grande leva mais tempo do que gerá-lo levou.

Verificações de tipo e testes unitários confirmam que o código faz o que foi escrito para fazer. Eles não conseguem dizer se a aplicação implantada ainda funciona, porque nunca abrem uma. É nessa lacuna que as regressões geradas por IA realmente vivem.

O ciclo, em três comandos

Instale o TestSprite CLI de código aberto — gratuito, Apache-2.0, Node 20.19+, 22.13+ ou 24+:

npm install -g @testsprite/testsprite-cli
testsprite setup

Depois o ciclo. Descreva o comportamento que você quer garantido, execute-o contra um navegador real e leia o veredito a partir do código de saída:

# 1 — create the test and run it
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: the run failed

# 2 — pull ONE self-consistent failure bundle
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — fix the code, then replay the same test
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: passed

O pacote na segunda etapa é a parte que importa. Ele contém a etapa que falhou, suas etapas vizinhas, capturas de tela, snapshots do DOM, o código-fonte do teste, uma hipótese de causa raiz e um alvo de correção recomendado — tudo compartilhando um único id de snapshot. O CLI se recusa a combinar dados de duas execuções diferentes, então um agente nunca está raciocinando sobre um contexto montado a partir de dois estados diferentes da aplicação.

Por que uma suíte durável supera uma janela de contexto maior

Todo teste que passa fica registrado. Na próxima vez que o agente tocar no código-fonte, aquele requisito ainda está sendo verificado — esteja ou não em algum lugar da conversa atual.

Este é o argumento estrutural para a verificação externa. Uma janela de contexto guarda o que o agente está pensando agora. Uma suíte de testes guarda todo requisito que o projeto já acertou, e continua guardando isso entre sessões, entre agentes e ao longo dos meses em que ninguém mais lembra por que um determinado caso extremo importava.

Configure seu agente para fazer isso sozinho

Você não deveria precisar retransmitir comandos entre uma página web e seu agente de codificação. Um único comando de configuração instala um arquivo de skill no repositório descrevendo o ciclo na forma que um agente realmente consome:

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

Os harnesses suportados são claude, codex, cursor, cline, antigravity, kiro, windsurf e copilot. A instalação é puramente local. Depois disso, o agente sabe como criar, executar e triar testes sem precisar ser informado novamente em cada sessão.

Antes de gastar um turno em um comando que vai falhar por motivos ambientais, verifique o ambiente:

testsprite doctor    # CLI and Node versions, profile, credentials, connectivity

O que verificar primeiro

Nem tudo merece um teste de ponta a ponta. Em uma base de código mudando rapidamente sob um agente de IA, a cobertura de maior valor é estreita:

1. Os fluxos que geram receita. Cadastro, checkout e cobrança. Uma regressão aqui custa dinheiro imediatamente e é frequentemente invisível em testes unitários.

2. Qualquer coisa envolvendo autenticação. Gerenciamento de sessão, redirecionamentos após login e limites de permissão são onde uma refatoração aparentemente plausível causa mais dano.

3. Formulários e validação. Baratos de descrever, desproporcionalmente propensos a quebrar quando uma biblioteca de componentes é atualizada ou um campo é renomeado.

4. Os últimos três bugs que você lançou. Um teste de regressão escrito depois de uma correção é o teste de maior retorno em qualquer suíte.

Se você preferir que o primeiro conjunto seja proposto para você, a exploração pode rascunhá-los. As propostas ficam em espera para revisão e nada é gravado no seu disco até que você aceite:

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # all of them
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

Tornando a verificação obrigatória

Uma etapa de verificação que só roda quando alguém lembra de executá-la não é verificação. Coloque-a no CI:

testsprite ci init github

Isso monta .github/workflows/testsprite.yml usando TestSprite/testsprite-action@v1, que anota a aba de checks do PR com um erro por falha, adiciona uma tabela de resultados ao resumo do job, envia um relatório JUnit e — o mais importante — falha o job em uma execução parcial em vez de reportá-la como verde.

Esse é o caminho em que seu workflow conduz a execução. O TestSprite também se instala como um GitHub App que escuta os eventos de implantação que seu pipeline já produz e comenta os resultados de volta no pull request, o que não exige arquivo de workflow nem nenhuma alteração no repositório.

Em qualquer outro sistema de CI, o CLI precisa apenas de uma chave de API no ambiente:

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

Códigos de saída que vale a pena ramificar

Os códigos 129, 130 e 143 significam que o processo foi interrompido por um sinal (128 mais o número do sinal), não que um teste falhou — vale a pena distinguir isso antes de reportar uma execução como quebrada.

Perguntas frequentes