Testes agênticos: o agente encontra o caminho até o objetivo

O que é teste agêntico

Teste agêntico é entregar ao agente o objetivo em vez dos passos: você declara a meta (por exemplo, "o pull request de um agente de código compila e passa nos testes") e o agente descobre sozinho o caminho até lá, contra a interface que o sistema expõe. A analogia central do texto: um teste com script é uma rota gravada; um teste agêntico é um destino. A gravação quebra quando alguém renomeia um campo; o destino sobrevive, porque o agente encontra um novo caminho.

Por que testes escritos quebram

Todo teste tradicional congela duas coisas: o locator (o nome do elemento a agir: um data-testid, uma rota, um import) e o oracle (a verificação que decide se a resposta está correta, como um assert de status). Congelar ambos é o que torna a suíte rápida, barata e determinística - a base de um portão de release confiável. Mas isso cobra um preço em três pontos: o locator quebra com renomes e mudanças estruturais mesmo com a feature funcionando; o oracle só cobre o que alguém pensou em testar; e nada na gravação registra a intenção, o que o sistema deveria fazer.

O autor adverte sobre "self-healing locators": eles consertam o locator apontando para o elemento que hoje faz aquele trabalho, o que mascara regressões em que o trabalho migrou para outro elemento - a suíte fica verde sobre uma feature quebrada.

Como funciona o loop

O agente opera em um ciclo simples: ler o estado, agir na direção do objetivo, ler de novo, repetir até cumprir a meta ou esgotar tentativas. São três trabalhos: explorar (mapear o sistema e planejar casos, incluindo caminhos que ninguém listou), gerar (escrever casos como arquivos de teste comuns, commitáveis) e reparar (reapontar passos quebrados ao novo alvo). Nada disso depende de imagem: em apps web o agente lê a árvore de acessibilidade (papéis, nomes e estados dos elementos), em APIs lê o schema, em código lê assinaturas e grafo de chamadas. Agentes de reparo rodam sobre MCP e, quando concluem que o app quebrou e não o próprio locator, não falham o build: marcam o teste como pulado e deixam um comentário - ninguém decidiu remover aquele fluxo da cobertura, o agente fez isso.

Um limite importante: o gerador escreve o oracle em um arquivo, que pessoas revisam e o CI executa sem modelo. A alternativa - deixar o modelo julgar se a resposta está certa - torna o portão de release não determinístico. Por isso o autor recomenda rodar cada teste pelo menos três vezes e reportar pass^k (todos os passam), não pass@k (algum passa). Em seu experimento com cinco verificações, uma foi instável: pass@3 de 0,6 contra pass^3 de 0,4 - um único teste decidiu se se envia ou não.

Quem está usando

A Meta rodou o TestGen-LLM no Instagram e Facebook com três filtros automáticos: compila, passa de forma confiável e eleva cobertura. 75% compilaram, 57% passaram consistentemente, 25% elevaram cobertura; engenheiros aceitaram 73% do que sobreviveu, e a maior parte da saída foi descartada. A Uber usa o AutoCover, que escreve cerca de um em cada nove testes novos do codebase, com taxa de testes viáveis de 20% em Java, 40% em Go e 80% em Python - diferença lida como custo de configuração. O Airbnb migrou quase 3.500 arquivos de teste do Enzyme em seis semanas (estimativa manual: ano e meio), com 75% em quatro horas e 97% em quatro dias, usando cadeias de validação com retentativas; a maior parte dos arquivos converge em até dez tentativas, e a cauda longa exigiu entre cinquenta e cem, com prompts de 100 mil tokens e até cinquenta arquivos de contexto.

Riscos e exageros

O reparo é a parte que engana: não distingue edição inofensiva de regressão, e quando não consegue reapontar marca o teste como pulado - verde de qualquer forma. A revisão humana não resolve, porque testes gerados se parecem demais com os escritos por pessoas; o autor sugere ler primeiro as asserções. Há também custo por passo: suíte gravada não tem custo de modelo; agente dirigindo o CI vira linha de conta. A promessa de fim da manutenção não se cumpre - troca-se manutenção visível (locator quebrado, barato e barulhento) por manutenção invisível (oracle que responde diferente na terça e na segunda).

Conclusão

O formato que vale hoje: agente na autoria, modelo fora do CI - ele explora e gera contra staging com supervisão, um revisor lê a saída como qualquer PR, e o CI roda código commitado sem modelo. O teste agêntico não remove a verificação; muda quem a escreve, e a discussão real é onde parar essa mudança.