Testes Agentes revelam gargalo de custo, não solução de CI

Slack realizou mais de 200 testes de ponta a ponta de interface do usuário utilizando métodos agentes em ambientes fora de produção, revelando uma taxa de falha de zero por cento para os fluxos mais simples, mas uma taxa de 48 por cento para a abordagem de script gerado no fluxo mais complexo, e 12 por cento mesmo para o melhor desempenho do agente apoiado por MCP nessa mesma fluxo. Isso indica que a verificação agente atua como uma camada de depuração em vez de um substituto completo de CI. A equipe de engenharia do Slack testou três arquiteturas de automação distintas contra dois fluxos de produto reais para determinar a posição apropriada dos testes agentes na pilha de testes.

O conjunto de ferramentas opera o Claude Code não interativo via `claude -p`. Para execução agente-dirigida, o Claude Sonnet 4.5 planeja e executa ações de navegador, enquanto o Claude Opus 4.6 traduz a intenção de linguagem natural em scripts determinísticos do Playwright. Dois modos de invocação baseados em Playwright foram avaliados contra a abordagem de script gerado. O primeiro envolvia um agente chamando um servidor MCP do Playwright que mantém o contexto de navegador persistente em uma sessão completa. O segundo tinha o agente emitindo comandos sequenciais da CLI do Playwright, reconstruindo o estado a partir de snapshots em cada passo. A configuração do ambiente foi gerenciada por um MCP da API de Desenvolvimento do Slack. Os fluxos de validação incluíram uma jornada de Resposta em Tópico com 15-20 etapas e uma jornada de Descoberta de Busca com 25-30 etapas, cada uma executada vinte vezes por configuração contra ambas as entradas de linguagem natural e estruturadas YAML.

O agente apoiado por MCP atingiu uma taxa de falha de zero por cento para o fluxo simples de Resposta em Tópico e uma taxa de falha de doze por cento para o fluxo mais complexo de Descoberta de Busca, com uma média de cinco a oito minutos por execução. O agente impulsionado por CLI falhou em doze por cento das execuções simples e vinte por cento das complexas, levando nove a onze minutos devido à sua reconstrução de estado em cada passo. O método de script gerado foi o mais rápido, com cerca de três minutos, mas o menos confiável, falhando em oito por cento das execuções de Resposta em Tópico e quarenta e oito por cento em Descoberta de Busca. O Slack atribui essa diferença ao contexto DOM persistente fornecido pelo MCP, em oposição ao desvio de estado introduzido pela reconstrução de snapshot do CLI em fluxos mais longos.

Custo e latência tornam cada variação inadequada para integração contínua. Cada execução custa entre quinze a trinta dólares e leva mais de dez minutos nos modos impulsionados por agente, sem a oferta de preços em nível de token ou desdobramentos de horas de GPU. Tanto a postagem de engenharia do Slack quanto um resumo do InfoQ posicionam o teste agente como um quarto nível na pirâmide de testes, acima de unidade, integração e testes E2E determinísticos, reservado para testes exploratórios, reprodução de problemas de produção e depuração de fluxos inconsistentes. Os agentes são restritos por listas de permissões de ação, limites de exploração e condições de parada explícitas, com observabilidade fornecida por logs de execução estruturados e rastros reprodutíveis.

O principal desafio não é a integração de ferramentas, mas a troca de custo-confiabilidade em fluxos complexos. Os testes gerados degradam significativamente à medida que o número de etapas aumenta, e mesmo o modo agente de melhor desempenho ainda falha em uma em oito jornadas complexas. As asserções determinísticas são difíceis de manter devido aos agentes potencialmente alcançando o mesmo objetivo por diferentes caminhos de navegação, métodos de entrada ou etapas puladas. Além disso, não há discussão sobre superfícies de injeção de prompt no contexto do MCP do navegador, o que permanece como uma questão aberta para quem expõe uma ferramenta consciente de DOM a um LLM.

Recomenda-se o padrão de fornecer ao seu agente de navegador contexto MCP persistente em vez de snapshots de shell e mantê-lo fora do portão CI até que o custo e a latência por execução sejam reduzidos por uma ordem de magnitude.