Playwright vs Cypress

Contexto

O que separa Playwright de Cypress não é o objetivo — os dois automatizam um browser real para testar a aplicação como um usuário faria — é onde o código de teste efetivamente roda. Cypress roda o código de teste dentro do próprio browser, no mesmo run-loop em que a aplicação sob teste executa: o teste e a página compartilham o mesmo contexto de JavaScript. Playwright roda fora do processo do browser, controlando-o através de um protocolo próprio de automação, de forma parecida com o que o Chrome DevTools Protocol faz para Chromium — só que Playwright implementa esse controle também para Firefox e para o motor real do WebKit (o mecanismo do Safari), não apenas para navegadores baseados em Chromium.

Essa diferença de modelo de execução não é só um detalhe de implementação: ela explica por que os dois têm capacidades diferentes em cenários como múltiplas abas, múltiplas origens e paralelização.

Quando escolher Playwright

Playwright é a escolha natural quando a matriz de compatibilidade do produto inclui Safari: como Cypress não tem um motor WebKit real, não há como validar comportamento específico do Safari sem Playwright (ou um serviço de nuvem que rode Safari de verdade). O modelo fora do processo também torna nativo testar fluxos com múltiplas abas ou múltiplas origens, como um checkout que abre um provedor de pagamento em outra aba:

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

test("abre nova aba e valida conteúdo", async ({ context, page }) => {
  await page.goto("/checkout");
  const [popup] = await Promise.all([
    context.waitForEvent("page"),
    page.getByRole("link", { name: "Pagar" }).click(),
  ]);
  await expect(popup.getByText("Pagamento aprovado")).toBeVisible();
});

O context acima representa um ambiente de browser isolado que pode abrir múltiplas páginas (abas) e ser inspecionado de fora — algo direto em Playwright porque o teste nunca esteve "dentro" do browser para começo de conversa. Playwright também tem sharding nativo no próprio test runner para paralelizar a suíte entre múltiplas máquinas ou processos, sem depender de um serviço externo pago para isso, e o Trace Viewer grava uma timeline completa (screenshots, DOM, rede) de uma execução para depuração pós-falha.

Quando escolher Cypress

Cypress compensa quando o time já tem fluência com o Cypress App — a interface visual que mostra cada comando do teste lado a lado com o estado da aplicação no momento exato daquele comando, inclusive permitindo "viajar no tempo" entre os passos do teste durante a depuração local:

describe("checkout", () => {
  it("mostra confirmação após pagar", () => {
    cy.visit("/checkout");
    cy.contains("Pagar").click();
    cy.contains("Pagamento aprovado").should("be.visible");
  });
});

Essa API encadeada (cy.visit, cy.contains, .should) é declarativa e enxuta, e a experiência de depuração interativa do Cypress App continua sendo um diferencial forte para quem já está confortável com esse fluxo de trabalho. Rodar o teste dentro do mesmo contexto de JavaScript da aplicação também simplifica certos tipos de interceptação de rede e stub. O outro lado dessa mesma arquitetura é a cobertura de browsers: o suporte estável de Cypress cobre a família Chromium e Firefox, e o WebKit segue marcado como experimental — e, de forma um tanto irônica, esse modo experimental é construído sobre o próprio binário WebKit do Playwright (playwright-webkit), não sobre uma integração independente. Some a isso um suporte a múltiplas origens historicamente mais recente e mais restrito do que o de Playwright, e a dependência do Cypress Cloud (serviço pago) para paralelização gerenciada em CI.

Veredito

A resposta começa pela cobertura de browsers que o produto realmente precisa validar, não por qual ferramenta parece mais moderna. Se a cobertura de Safari/WebKit importa, se os fluxos testados envolvem múltiplas abas ou origens, ou se paralelização nativa sem serviço externo é um requisito, Playwright cobre esses casos de forma mais direta. Se o time já tem fluência com o Cypress App e o alvo real de produção é majoritariamente Chromium/Firefox, a experiência de depuração interativa do Cypress continua sendo um motivo legítimo para ficar com ele.

Vale um inventário rápido antes de bater o martelo: quantos fluxos do produto realmente precisam do WebKit, e quanto a equipe já depende do replay interativo do Cypress App para depurar falhas no dia a dia? A resposta a essas duas perguntas pesa mais do que qualquer benchmark de velocidade entre os dois runners.