O que é Playwright

O Playwright e um framework de automação para testes de aplicações web. Ele abre navegadores, interage com elementos, valida resultados e registra evidências quando algo falha.

O projeto foi criado pela equipe que trabalhou no Puppeteer e e mantido como software open source. A proposta e oferecer uma API consistente para Chromium, Firefox e WebKit.

Ele ganhou espaço em equipes que precisam testar login, checkout, formulários e áreas autenticadas. A combinação de esperas automáticas, isolamento de contexto e depuração aproxima o teste do uso real.

*
Dica

Comece automatizando um fluxo crítico e estável. Um teste pequeno e confiável vale mais do que uma grande suite difícil de manter.

Como funciona

O Playwright inicia o navegador e cria um contexto isolado para cada conjunto de testes. Cookies, armazenamento local e sessões ficam separados.

O teste abre páginas e localiza elementos por papel, texto, label ou atributo observável. A API aguarda que o elemento esteja pronto, reduzindo esperas fixas e corridas.

O runner organiza fixtures, tentativas, screenshots, vídeos e traces. Esses recursos ajudam a entender a falha em vez de depender apenas de uma mensagem curta no terminal.

Principais recursos

O recurso mais conhecido e a automação com a mesma estrutura em Chromium, Firefox e WebKit. Projetos diferentes podem ter configurações de navegador e viewport próprias.

Locators orientados ao comportamento do usuário tornam o teste mais legível. Em vez de um seletor CSS frágil, o código pode procurar um botão pelo papel e nome visível.

Trace viewer, screenshots, vídeos e paralelismo ajudam a investigar falhas em pipelines de integração continua.

  • Multi navegador: execute o mesmo fluxo em três motores.
  • Locators: encontre elementos por papel, texto e label.
  • Trace viewer: reveja passos, rede e evidências.

Como começar: instalação ou acesso passo a passo

Em um projeto Node.js, instale o Playwright Test. O pacote inclui o runner e permite configurar projetos em arquivo versionado.

Depois, instale os navegadores gerenciados e crie um arquivo de teste. Rode primeiro em modo visível e só então adicione o teste ao pipeline.

Configure comandos separados para desenvolvimento e CI. Defina também onde os artefatos de falha serão guardados.

npm init playwright@latest
npx playwright install
npx playwright test
!
Atenção

Os navegadores precisam ser instalados no ambiente da pipeline. Instalar apenas o pacote npm não garante que o agente de CI tenha os binários.

Exemplo prático

Considere uma página de login com campos identificados por label e um botão Entrar. O teste abre a página, preenche credenciais de teste e verifica a navegação para o painel.

Use dados sem informações pessoais e mantenha a conta isolada da produção. O objetivo e validar o comportamento sem expor dados reais.

import { test, expect } from '@playwright/test';

test('usuário acessa o painel', async ({ page }) => {
  await page.goto('https://exemplo.test/login');
  await page.getByLabel('E-mail').fill('[email protected]');
  await page.getByLabel('Senha').fill('senha-de-teste');
  await page.getByRole('button', { name: 'Entrar' }).click();
  await expect(page).toHaveURL(/painel/);
});

O locator por label comunica a intenção e sobrevive melhor a mudanças visuais. A asserção de URL confirma o resultado, mas também é possível validar titulo ou mensagem.

Comparação com alternativas

O Selenium tem ecossistema amplo e continua comum em empresas com suites antigas ou requisitos específicos de WebDriver. Ele pode exigir mais configuração para sincronização.

O Cypress oferece experiência integrada para testes em navegador e boa depuração. A escolha depende do modelo de execução, navegadores exigidos e controle sobre rede e sessões.

O Playwright faz sentido quando a equipe quer uma API moderna, vários motores e recursos fortes de investigação. Em uma suite pequena e estável, migrar pode custar mais que o ganho imediato.

Pontos positivos e limitações

Entre os pontos positivos estão navegadores integrados, locators orientados ao usuário e trace. O isolamento por contexto facilita rodar testes sem compartilhar estado por acidente.

A limitação e o custo de manter testes de interface. Mudanças no fluxo, textos, permissões e dados podem quebrar a suite mesmo quando a regra de negócio continua correta.

CPU e memoria crescem quando muitos navegadores rodam ao mesmo tempo. Em CI, dimensione agentes e defina limites de paralelismo.

*
Cuidado

Não use esperas fixas longas para mascarar flakiness. Investigue a condição que indica que a página esta pronta.

Casos de uso reais

Uma equipe de produto pode validar cadastro, recuperação de senha e compra antes de cada release. Esses testes verificam fluxos de maior valor.

Uma software house pode criar projetos para navegadores e dispositivos diferentes. O mesmo comportamento e verificado em uma matriz relevante para os clientes.

Times de DevOps podem executar a suite em cada pull request e publicar traces quando houver falha. O desenvolvedor recebe evidência reproduzível na CI.

Também é possível usar a ferramenta para acessibilidade, contratos visuais e áreas autenticadas, sempre com objetivo claro e dados controlados.

Dicas e boas práticas

*
Dica 1 - Prefira locators semânticos

Use role, label e texto visível quando representam o contrato da interface. O teste fica próximo da experiência de quem usa o produto.

*
Pro tip - Separe dados e fluxo

Crie fixtures para preparar usuários e estados. O teste deve explicar o comportamento, não repetir toda a preparação.

!
Atenção - Controle o paralelismo

Aumente workers aos poucos e observe a pipeline. Mais paralelismo nem sempre significa conclusão mais rápida.

Ative traces e screenshots para falhas e defina retenção. Artefatos devem ajudar sem expor credenciais ou dados sensíveis.

Rode a suite em ambiente previsível e use contas de teste. Se o objetivo não for integrar um serviço externo, use um stub.

Vale a pena?

O Playwright vale a pena para equipes que precisam validar fluxos web em mais de um navegador. A curva inicial compensa quando a suite encontra regressions antes da publicação.

Ele não substitui testes unitários, de integração ou revisão manual. Testes de navegador devem cobrir caminhos críticos, enquanto regras menores ficam em camadas rápidas.

O próximo passo e escolher um fluxo essencial, escrever um teste com locators semânticos e executar localmente. Depois, publique artefatos de falha na CI.