Testes Playwright gerados por IA: como evitar falsos positivos

O que exatamente ficou verde? Um teste Playwright pode clicar no botão certo, encontrar um toast de sucesso e ainda deixar um pedido sem persistir. O código passa. A regra de negócio não.

Esse é o risco mais traiçoeiro dos testes gerados por IA: eles parecem completos porque reproduzem a sequência visível. A validação começa quando você troca a pergunta "o teste rodou?" por "qual estado do sistema ele provou?".

Se você ainda precisa da base de automação, comece pelos testes end-to-end com Playwright. Este texto parte daí e trata do problema que aparece quando o arquivo foi escrito por um agente.

Resumo prático

• Trate o teste gerado como um rascunho, não como prova automática.
• Escreva a consequência de negócio antes de aceitar locators e cliques.
• Execute o navegador e verifique estado observável além de mensagens temporárias.
• Guarde trace, relatório e diff do reparo antes de colocar o teste no CI.

O verde pode ser enganoso

Um teste E2E é útil quando liga uma ação do usuário a uma consequência que importa para o produto. A documentação do Playwright recomenda testar o comportamento visível e usar asserções web-first, mas um agente ainda pode escolher o sinal mais barato para produzir um resultado verde. O executor precisa revisar essa escolha.

O falso positivo aparece quando a asserção confirma um detalhe intermediário. Um toast pode informar que a requisição começou. Um redirecionamento pode acontecer antes de o backend salvar os dados. Um locator pode encontrar um elemento escondido. Em todos esses casos, a sequência parece correta sem fechar o contrato do fluxo.

Compare os dois testes:

test("finaliza o checkout", async ({ page }) => {
  await page.getByRole("button", { name: "Pagar" }).click();
  await expect(page.getByRole("status")).toHaveText("Pedido criado");
});

O primeiro teste só verifica uma mensagem. Uma versão mais forte consulta a página de confirmação e, quando o produto permite, confere o estado por uma API de leitura criada para testes:

test("finaliza o checkout", async ({ page, request }) => {
  await page.getByRole("button", { name: "Pagar" }).click();

  await expect(page).toHaveURL(/\/pedidos\/[a-z0-9-]+/);
  await expect(page.getByRole("heading", { name: "Pedido confirmado" })).toBeVisible();

  const orderId = await page.getByTestId("order-id").textContent();
  const response = await request.get(`/api/test/orders/${orderId}`);

  expect(response.ok()).toBe(true);
  expect(response.status()).toBe(200);
  expect(await response.json()).toMatchObject({ state: "created" });
});

O endpoint de leitura é apenas um exemplo. Não exponha dados internos para o browser do usuário só para facilitar um teste. Se a API não existir, valide a consequência pela interface, por uma fila de teste ou por outro artefato seguro que o sistema já produza.

Cápsula citável: Um teste Playwright gerado por IA pode ficar verde ao verificar apenas um toast, um redirecionamento ou um locator presente. A documentação do Playwright recomenda asserções que aguardam o estado esperado. Para evitar falso positivo, o teste também precisa confirmar a consequência de negócio que o usuário deveria observar.

O contrato vem antes do arquivo .spec.ts

Comece por uma frase que descreva a regra, não pela implementação. O contrato deve dizer quem inicia o fluxo, qual estado precisa existir antes, qual ação ocorre e qual evidência confirma o resultado. Essa frase vira a régua para revisar o arquivo .spec.ts gerado pelo agente.

## Checkout aprovado

- Dado: um carrinho com um produto disponível e um usuário autenticado.
- Quando: o usuário confirma o pagamento aprovado.
- Então: o pedido aparece como criado, recebe um identificador e o carrinho fica vazio.
- Não prova: somente a presença de um toast ou a mudança de URL.

O Playwright fornece planner, generator e healer para explorar uma aplicação, criar testes e propor reparos. A documentação também mantém o requisito de seed test, plano legível e arquivos auditáveis. O agente pode preencher o esqueleto, mas a equipe ainda decide se a asserção representa a regra.

Use esta lista antes de revisar detalhes de estilo:

O último item merece atenção. Corrigir um locator é diferente de alterar o resultado esperado. O primeiro pode acompanhar uma mudança de interface. O segundo pode esconder uma regressão. Essa diferença deve aparecer no pull request e no relatório do CI.

O contrato também conversa com a visão geral dos tipos de testes de software. O teste E2E cobre o fluxo completo, mas a regra de negócio pode precisar de um teste de integração ou de uma leitura controlada do serviço.

Locators, asserções e estado formam três verificações

A verificação precisa acontecer em três camadas. Primeiro, confirme que o locator descreve o elemento como o usuário o encontra. Depois, use uma asserção que aguarde o estado. Por fim, confira o efeito que existe fora do elemento usado para iniciar a ação.

O Playwright recomenda priorizar locators voltados ao usuário, como getByRole, getByLabel e getByTestId, em vez de cadeias frágeis de CSS ou XPath (Playwright, melhores práticas, consultado em 28/07/2026). Isso não torna o teste automaticamente bom. Um locator semântico ainda pode apontar para o elemento errado se a asserção for fraca.

test("atualiza o endereço exibido no perfil", async ({ page }) => {
  await page.getByLabel("Rua").fill("Rua das Flores, 10");
  await page.getByRole("button", { name: "Salvar endereço" }).click();

  await expect(page.getByRole("status")).toHaveText("Endereço salvo");
  await expect(page.getByLabel("Rua")).toHaveValue("Rua das Flores, 10");
  await expect(page.getByTestId("profile-address")).toContainText("Rua das Flores, 10");
});

Aqui, o status informa que a operação foi aceita, o campo mostra o valor local e o resumo do perfil confirma o estado visível. Em um sistema com persistência assíncrona, acrescente uma leitura segura ou reabra a tela em um novo contexto para evitar testar apenas memória do browser.

Não transforme cada detalhe em uma asserção. O objetivo é provar o contrato, não congelar toda a estrutura HTML. Também evite waitForTimeout como reparo automático. Se o agente não consegue explicar qual condição precisa ser aguardada, o problema está no teste ou no produto, não na falta de uma pausa arbitrária.

Cápsula citável: Locators voltados ao usuário tornam o teste mais resistente a mudanças internas, mas não eliminam falsos positivos. A verificação completa combina ação, asserção web-first e uma consequência de negócio observável. Se o healer troca a expectativa, o diff precisa de revisão humana antes de entrar na suíte estável.

A evidência precisa viajar com o teste

O mínimo é um arquivo de teste legível, o comando executado, o resultado, o trace quando houver falha e a diferença proposta pelo agente. Essa coleção permite responder se o teste falhou por regressão, ambiente, locator obsoleto ou expectativa errada. Sem ela, o CI só entrega uma cor.

Configure o runner para preservar trace na primeira repetição em CI:

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  forbidOnly: Boolean(process.env.CI),
  retries: process.env.CI ? 1 : 0,
  reporter: [["html", { open: "never" }]],
  use: {
    baseURL: "http://127.0.0.1:3000",
    trace: "on-first-retry",
    ...devices["Desktop Chrome"],
  },
});

O Playwright documenta on-first-retry como uma forma de coletar trace quando a falha se repete, sem gravar esse artefato pesado em toda execução (Playwright, trace viewer, consultado em 28/07/2026). O trace mostra ações, snapshots do DOM, rede, console e erros. Ele não substitui a revisão da regra, mas reduz a adivinhação sobre o que aconteceu.

Em loops longos que alternam agente, navegador, logs e revisão, uso o RemoteCode para fazer Claude Code e Codex irem mais longe com menos contexto repetido. É uma ferramenta minha, então a recomendação é editorial e ligada ao custo de carregar evidência, não uma promessa de que ela valida o teste.

O CI julga o artefato, não a narrativa

O caminho mais curto é tratar o teste gerado como código de pull request. O agente abre o arquivo, o CI executa o fluxo e um job publica os artefatos. A aprovação só acontece quando o teste prova o contrato e o diff do agente não altera a expectativa sem revisão.

Uma sequência simples para um projeto Node.js é:

npm ci
npx playwright install --with-deps chromium
npx playwright test tests/checkout.spec.ts --reporter=line
npx playwright show-report

Verifique localmente com um caminho quebrado de propósito. Remova temporariamente o data-testid="order-id" ou faça a API de teste devolver state: "pending". O teste deve falhar pela razão esperada. Depois restaure o comportamento e confirme que a execução volta a passar. Esse teste de mutação manual é mais informativo que olhar somente para o primeiro verde.

No CI, armazene playwright-report e test-results quando houver falha. Para um fluxo de agente, registre também o plano original, o hash do commit, o nome do modelo ou ferramenta quando disponível e o diff do reparo. Não envie credenciais, cookies ou payloads sensíveis ao relatório.

Esse artefato complementa os evals de regressão para agentes de código: o eval pergunta se o patch preservou comportamento, enquanto o teste de navegador fornece uma prova concreta para aquele fluxo.

Cápsula citável: O CI deve julgar o arquivo gerado pela evidência que ele produz, não pelo texto do agente. Playwright oferece relatório e trace para depurar falhas. Um gate confiável executa o fluxo, verifica o resultado esperado, preserva artefatos e bloqueia alterações silenciosas na expectativa.

Erros comuns ao revisar testes de agentes

Um erro comum é aceitar uma asserção que só confirma que a interface reagiu. Troque mensagens temporárias por estado persistido, confirmação em uma tela independente ou leitura controlada do serviço. Também não deixe o healer editar a expectativa sem revisão. Correções mecânicas de locator são uma coisa; mudar o que conta como sucesso é outra.

É fácil confundir retry com confiabilidade. O Playwright classifica testes que passam apenas após retry como flaky; repetir a execução ajuda a diagnosticar, mas não transforma a instabilidade em prova (Playwright, retries, consultado em 28/07/2026). Um retry limitado deve gerar um sinal para o time, não esconder a causa.

O isolamento costuma ser esquecido quando o agente recebe apenas a tela e o requisito. A documentação de melhores práticas do Playwright recomenda separar dados e contexto de cada teste para melhorar a reprodução e evitar falhas em cascata. Sem fixtures e pré-condições claras, o arquivo pode passar apenas porque outra execução deixou estado no ambiente. A referência completa está na lista de fontes.

Cobertura de linhas também engana. Um teste pode atravessar muitas funções sem verificar a decisão relevante. Relacione o caso ao requisito, ao risco e ao resultado observável. Cobertura ajuda a localizar código sem teste; não decide se a asserção prova a regra.

Quando a suíte cresce, registre essa evidência na observabilidade de agentes de código no CI. Nome do teste, commit, tentativa e artefato formam uma trilha curta para separar falha de produto, ambiente e reparo automático.

Limites dessa abordagem

Nenhum checklist impede todos os defeitos. Um teste E2E não prova cada combinação de dados, não substitui testes unitários e não garante que um serviço externo esteja disponível. A validação também não detecta sozinha uma regra de negócio incorreta. Ela apenas torna o erro mais difícil de esconder.

Para pagamentos, permissões, migrações, dados pessoais e integrações com efeito externo, exija testes de contrato, ambiente descartável e aprovação humana. Um agente pode sugerir o caso e escrever o esqueleto, mas a equipe precisa decidir se o cenário é seguro, determinístico e representativo.

O Playwright Test Agents são úteis para explorar, gerar e reparar testes, mas a documentação descreve um fluxo que ainda produz arquivos e planos revisáveis. Use essa separação como princípio: automatize a produção, preserve a prova e deixe mudanças de intenção explícitas.

Esse é o mesmo limite defendido por um harness de agentes de código para PRs confiáveis: cada etapa pode ser rápida, mas a mudança final precisa chegar pequena, rastreável e verificável.

Perguntas frequentes sobre testes Playwright gerados por IA

Um teste Playwright gerado por IA substitui a revisão humana?

Não. O agente pode criar locators e asserções válidos, mas não deve decidir sozinho se o caso prova a regra do produto. A pessoa revisora precisa comparar requisito, fluxo, estado final, dados de teste e diff do reparo antes de adicionar o teste à suíte estável.

Como saber se uma asserção de Playwright é fraca?

Ela é fraca quando pode passar sem confirmar a consequência principal. Um toast, uma URL ou um elemento visível podem ser sinais úteis, mas não bastam se o requisito envolve persistência, cálculo, permissão ou envio. Acrescente uma verificação independente e execute um caminho que deveria falhar.

O healer pode alterar um teste automaticamente?

Pode propor uma correção mecânica, como atualizar um locator que mudou, desde que o diff fique visível. Não aceite automaticamente alterações no resultado esperado, na regra de negócio, na condição de erro ou no escopo do cenário. Essas mudanças precisam de revisão humana e evidência nova.

Devo usar trace em toda execução?

Não é necessário. Em CI, on-first-retry preserva evidência quando um teste falha novamente, enquanto gravação contínua aumenta o custo dos artefatos. Em desenvolvimento, ligue trace quando estiver investigando uma falha específica e desligue depois de entender a causa.

Fontes consultadas

• Playwright, "Playwright Test Agents", consultado em 28/07/2026, https://playwright.dev/docs/test-agents
• Playwright, "Best Practices", consultado em 28/07/2026, https://playwright.dev/docs/best-practices
• Playwright, "Assertions", consultado em 28/07/2026, https://playwright.dev/docs/test-assertions
• Playwright, "Retries", consultado em 28/07/2026, https://playwright.dev/docs/test-retries
• Playwright, "Trace viewer", consultado em 28/07/2026, https://playwright.dev/docs/trace-viewer-intro
• Playwright, "Release notes", consultado em 28/07/2026, https://playwright.dev/docs/release-notes
• GitHub, "Building and testing Node.js", consultado em 28/07/2026, https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing/nodejs