5 dicas para usar Playwright Test Agents

A release estável consultada é a v1.64.1, publicada em 14 de outubro de 2026. O guia abaixo trata dos agentes da biblioteca principal, não da Playwright CLI, que já explicamos em outro artigo.

Playwright Test Agents organizam um ciclo, não uma equipe autônoma

O Planner explora a interface e transforma uma descrição do produto em um plano de testes. O Generator usa esse plano para criar testes Playwright. O Healer investiga falhas e propõe alterações para recuperar testes quebrados.

A documentação mostra os agentes trabalhando a partir de uma especificação inicial chamada seed.spec.ts. O Planner pode descobrir a interface e produzir casos; depois, o Generator converte os casos em testes automatizados.

O Healer entra quando um teste falha. Ele examina a execução, sugere uma correção e pode repetir o ciclo, mas um teste aprovado não prova sozinho que o produto está correto.

A biblioteca Playwright suporta Chromium, Firefox e WebKit por uma API comum, como descreve o README oficial. Esse alcance ajuda a testar diferenças entre navegadores, mas não elimina a necessidade de revisar quais navegadores e versões importam para o seu público.

Este artigo trata dos Test Agents do repositório microsoft/playwright. A Playwright CLI para interagir com um navegador é outro projeto e tem outro uso: comandos de navegador acionados pelo agente.

5 dicas para usar Playwright Test Agents com critério

Dica 1: entregue ao Planner um fluxo e um estado inicial claros

Comece com uma jornada curta, como entrar em uma página, preencher um formulário de teste e confirmar a mensagem final. Indique os dados disponíveis e o resultado esperado, sem misturar vários objetivos.

Um seed bem delimitado dá ao Planner um ponto de partida verificável. Se o agente não souber qual estado inicial usar, o plano pode refletir suposições sobre contas, permissões ou dados que não existem no ambiente.

Dica 2: revise o plano antes de pedir código ao Generator

Leia os passos e confira se cada caso corresponde a um requisito real. Remova ações repetidas, acrescente estados de erro importantes e corrija qualquer expectativa que não faça parte do produto.

A documentação oficial dos Test Agents mostra esse prompt de planejamento. A imagem é uma captura do pedido ao Planner, não um resultado de teste nem uma prova de que todos os cenários foram cobertos.

Dica 3: use o Generator para transformar critérios em verificações

Depois de aprovar o plano, peça ao Generator para criar testes alinhados aos passos e às regras de aceite. Prefira verificações do comportamento que a pessoa percebe, como mensagem de confirmação, estado salvo ou bloqueio de um formulário inválido.

Evite aceitar uma suíte que apenas repete detalhes internos da tela. Um teste preso a nomes de classes ou à ordem de componentes pode falhar por uma mudança visual sem que a experiência tenha sido quebrada.

Dica 4: trate o Healer como assistente de diagnóstico

Quando um teste falhar, examine a causa antes de deixar o Healer alterar o código. Uma falha pode revelar um defeito no produto, um dado de teste instável ou uma mudança legítima na interface.

Revise o diff proposto, confirme que a asserção continua medindo o requisito e rode a suíte relevante. Se a correção apenas remove a verificação que falhou, o teste pode ficar verde sem proteger o comportamento que motivou sua criação.

Dica 5: regenere definições e registre as decisões

Os agentes dependem de instruções e ferramentas compatíveis com a versão do Playwright usada no projeto. Quando atualizar a biblioteca, gere novamente as definições conforme a documentação e confira o diff antes de substituir arquivos existentes.

Mantenha no repositório os testes aprovados, não uma saída bruta do agente como se fosse uma especificação final. Registre quais requisitos cada teste cobre e quem revisou mudanças sugeridas pelo Healer.

Para levar testes a uma rotina automatizada, o artigo sobre GitHub Agentic Workflows e automação de repositórios explica outra camada de execução. Os agentes de teste e o fluxo de CI têm responsabilidades diferentes.

Segurança do Playwright exige separar a biblioteca da imagem Docker

O repositório usa licença Apache-2.0, como mostra o arquivo LICENSE, e a página de advisories consultada não lista aviso publicado. Isso não significa que toda imagem ou configuração de navegador seja automaticamente segura.

Uma issue do GitHub reporta 245 achados de CVE no scanner usado pelo autor para a imagem Docker baseada no Playwright v1.64.1, dos quais 24 foram classificados como críticos por ele. É um relato em issue, não um advisory oficial nem uma medida de exposição de cada ambiente.

A própria issue #43664 registra que uma atualização da imagem chegou a ser mesclada em main e foi revertida em 5 de novembro de 2026. Como a última release estável consultada continua na v1.64.1, não presuma que a revisão de Chromium mais nova esteja na imagem marcada apenas com essa versão.

Se sua equipe usa a imagem Docker, confira o histórico de atualização e a versão do Chromium dentro do próprio artefato. A página de security advisories do Playwright e a issue que relata a imagem v1.64.1 ajudam a separar avisos publicados de relatos ainda em discussão.

Execute testes em staging, com dados fictícios e permissões limitadas. Os Test Agents automatizam etapas de planejamento e execução, mas não isolam por conta própria um navegador que recebe credenciais ou acesso a dados reais.