Cypress ou Playwright: Qual Escolher em 2026?

Teve uma sexta-feira, lá na iPort, em que passei a tarde inteira brigando com um teste que funcionava perfeito no Chrome e quebrava sem explicação nenhuma no pipeline. O problema não era o código da aplicação — era o WebDriver do Selenium tentando simular um clique que cada navegador processava de um jeito diferente. Foi mais ou menos nessa época que ouvi falar de Cypress pela primeira vez, e alguns anos depois, já testando fluxos de pagamento na Entrepay, o Playwright apareceu como opção séria de verdade. Hoje, entre Cypress ou Playwright, a resposta direta é: se o seu projeto precisa rodar de verdade em WebKit (o motor por trás do Safari), se o time trabalha com Python, Java ou C# além de JavaScript, ou se paralelizar sem pagar por isso importa pro orçamento, vá de Playwright; se você foca só em aplicações web em JavaScript ou TypeScript, prioriza a experiência de depurar localmente e não se importa de eventualmente pagar pelo Cypress Cloud pra rodar em paralelo, o Cypress ainda entrega uma das melhores experiências de desenvolvimento que existem em automação de testes.

Cypress ou Playwright na arquitetura: por dentro do navegador ou por fora

A diferença que explica quase todas as outras entre as duas ferramentas começa antes de qualquer teste rodar, na forma como cada uma conversa com o navegador. O Cypress roda dentro do próprio navegador, no mesmo loop de execução da sua aplicação — o teste literalmente compartilha o contexto JavaScript da página que está sendo testada. Isso tem uma vantagem prática enorme: o Cypress enxerga o DOM em tempo real, sem precisar serializar comandos por um protocolo externo, e consegue esperar automaticamente que elementos apareçam, fiquem visíveis e parem de se mover antes de interagir com eles. Foi essa espera automática, aliás, que me converteu de vez quando troquei de Selenium pra Cypress: acabaram aqueles sleep(2000) espalhados pelo código só pra dar tempo do elemento carregar.

O Playwright resolve o mesmo problema de um jeito estruturalmente diferente. Ele fica fora do processo do navegador e conversa com ele via protocolo (o mesmo tipo de canal que as ferramentas de desenvolvedor do Chrome usam por trás dos panos), controlando abas, janelas e até múltiplos navegadores ao mesmo tempo a partir de um único processo de teste. Na prática, isso significa que o Playwright lida nativamente com contextos de navegador isolados — você pode abrir uma aba nova, simular dois usuários logados ao mesmo tempo em sessões separadas, ou seguir um fluxo que sai do seu domínio e vai pra um provedor externo, tudo sem gambiarra. A própria documentação oficial do Playwright sobre contextos de navegador mostra bem esse isolamento por padrão.

Essa parte é onde a arquitetura deixa de ser teoria e vira dor de cabeça real. Numa das minhas passagens testando fluxo de checkout, o processo de pagamento abria uma nova aba pra autenticação em duas etapas antes de voltar pro fluxo principal. Em Cypress, isso historicamente sempre foi um ponto fraco: o comando cy.origin() foi criado justamente pra dar um jeito de navegar entre origens diferentes, mas ele ainda opera dentro das limitações de rodar tudo num único contexto de navegador, então teste multi-aba continua sendo, na melhor das hipóteses, contornável, não natural. No Playwright, esperar a nova página abrir e trocar de contexto é parte do dia a dia da API — não é um caso especial que exige solução alternativa, é assim que a ferramenta foi desenhada desde o início.

Navegadores, linguagens e pra quem cada ferramenta foi pensada

Bora falar de números concretos, porque decisão de ferramenta não pode ser só sobre gosto pessoal. O Cypress cobre bem Chrome, Edge, Firefox e o próprio Electron (o motor que ele usa internamente), e desde 2022 tem suporte experimental a WebKit — mas “experimental” aqui é a palavra certa: recursos somem, bugs aparecem, e não é algo que eu recomendaria pra rodar numa suíte de produção que realmente depende de testar como o Safari se comporta. O Playwright, por outro lado, nasceu já pensando em cobertura ampla: Chromium, Firefox e WebKit rodam nativamente e são tratados como cidadãos de primeira classe, com o mesmo nível de suporte e manutenção.

Uma ressalva importante, que vale reforçar porque gera confusão: nenhuma das duas ferramentas controla um binário real do Safari ou testa em iOS de verdade — o que o Playwright oferece é o motor WebKit rodando em Linux, Mac ou Windows, o que cobre um bom pedaço dos bugs específicos de renderização, mas não substitui 100% um teste no Safari real da Apple. Do lado das linguagens, a diferença é ainda mais definitiva pra quem trabalha em time misto. Cypress é JavaScript e TypeScript, ponto final — se seu time inteiro já vive nesse ecossistema, isso nunca vai ser uma limitação de verdade. O Playwright, no entanto, oferece bindings oficiais pra TypeScript, JavaScript, Python, Java e C#, o que muda o jogo pra empresas onde o time de backend usa Java ou Python e quer escrever os próprios testes de ponta a ponta sem aprender um ecossistema JS inteiro só pra isso.

Vi isso de perto numa equipe que testava serviços financeiros: os desenvolvedores backend em Python conseguiam contribuir com testes de ponta a ponta usando Playwright sem sair da linguagem que já dominavam, algo que seria impensável pedir que aprendessem Cypress só pra escrever um teste de fluxo. Não encontrei uma pesquisa recente e confiável o suficiente sobre qual das duas ferramentas domina em adoção no mercado brasileiro especificamente — as pesquisas de comunidade tipo State of JS mostram o Playwright crescendo rápido em menções e satisfação desde 2022, mas trato isso como tendência internacional, não como número fechado, porque a metodologia varia bastante entre uma pesquisa e outra e a amostra raramente é representativa do Brasil.

Velocidade, paralelização e o custo que ninguém menciona no início

Rodar dois ou três testes localmente não deixa clara a diferença de performance entre as ferramentas — o problema aparece quando a suíte cresce pra centenas de testes e o pipeline de CI começa a demorar. Aqui a arquitetura de cada ferramenta volta a pesar: como o Playwright roda fora do processo do navegador, ele consegue dividir a suíte inteira entre múltiplos workers em paralelo de graça, sem custo adicional, usando só a configuração nativa do próprio framework. Numa máquina com mais núcleos, ou num runner de CI configurado certo, dá pra rodar a suíte inteira numa fração do tempo só ajustando o número de workers no arquivo de configuração. Isso por si só já é um bom motivo pra colocar isso na balança quando comparo Cypress ou Playwright pra um projeto novo.

O Cypress historicamente colocou a paralelização atrás de uma parede: rodar testes em paralelo de verdade, direto pela ferramenta, sempre exigiu uma assinatura do Cypress Cloud (o serviço pago da própria empresa por trás do framework) ou recorrer a uma grade de terceiros. Isso não é um defeito técnico — dá pra rodar Cypress em paralelo sem pagar nada usando ferramentas externas de orquestração de CI, dividindo os arquivos de teste manualmente entre jobs — mas exige mais configuração manual do que simplesmente ligar uma flag, que é basicamente o que o Playwright oferece de fábrica.

Na prática, o efeito colateral disso é financeiro antes de ser técnico: se você está calculando o custo real de manter uma suíte de testes de ponta a ponta, o orçamento de minutos de CI (que a maioria dos provedores cobra por minuto usado) tende a crescer mais devagar com Playwright justamente porque paralelizar não depende de um produto pago à parte. Isso não quer dizer que o Cypress “custa mais” no sentido absoluto — muita equipe roda Cypress em paralelo com ferramentas gratuitas e nunca sente esse problema — mas ao decidir entre Cypress ou Playwright vale colocar esse ponto na balança antes de escolher, principalmente se a suíte já nasce grande ou se o plano é escalar rápido.

Depuração no dia a dia: Time Travel contra Trace Viewer

De todas as diferenças entre as duas ferramentas, a experiência de depuração foi a que mais evoluiu nos últimos anos — e é também onde a preferência pessoal pesa mais do que dado técnico. O Cypress construiu a reputação dele em cima do runner interativo com “viagem no tempo”: cada comando do teste vira um snapshot clicável, e ao passar o mouse sobre qualquer passo da execução você vê exatamente como a tela estava naquele momento, sem precisar rodar o teste de novo. Pra quem está depurando um teste que falha de forma inconsistente, isso economiza um tempo enorme — foi a funcionalidade que mais me ajudou quando eu ainda estava pegando prática com automação e não sabia direito onde procurar o problema. É um detalhe pequeno, mas typical do tipo de coisa que pesa na hora de escolher entre Cypress ou Playwright no dia a dia.

O Playwright não tinha nada parecido nas primeiras versões, mas fechou essa distância de um jeito diferente: o Trace Viewer grava uma linha do tempo completa da execução (rede, console, DOM, screenshots por passo) que você abre depois, offline, inclusive a partir de um teste que rodou no CI — o que resolve um problema clássico de “no meu computador funciona”. Some a isso o modo UI, que roda os testes com uma interface visual parecida com a do Cypress, e o Codegen, que grava suas ações no navegador e já gera o código do teste automaticamente. Na minha experiência, o Trace Viewer é mais útil pra depurar falha que só acontece no pipeline, enquanto o runner do Cypress ainda ganha em fluidez pra quem está escrevendo e ajustando o teste pela primeira vez, direto na máquina.

Vale registrar uma tendência que só ganhou força recentemente: tanto o ecossistema em torno do Playwright quanto ferramentas de terceiros vêm incorporando sugestões geradas por inteligência artificial pra identificar seletores mais estáveis e sugerir consertos quando um teste quebra por causa de uma mudança pequena na interface. Se esse assunto te interessa, vale ver como a IA está mudando o trabalho de QA de um jeito mais amplo, porque o impacto vai muito além de só apontar seletores. Nenhuma das duas ferramentas te deixa na mão nesse quesito — se cinco anos atrás a depuração era motivo de peso pra escolher Cypress, hoje ela pesa bem menos na decisão do que suporte a navegador, linguagem do time ou custo de paralelização.

Quando eu escolheria cada um (e quando não vale migrar)

Depois de testar Cypress ou Playwright em contextos bem diferentes, cheguei numa régua simples que uso pra decidir, e vou compartilhar sem enrolação. Escolho Playwright quando o projeto é novo, quando existe chance real de precisar testar comportamento específico de WebKit/Safari, quando o time tem gente de fora do ecossistema JavaScript que também vai escrever teste, ou quando sei que a suíte vai crescer rápido e não quero depender de um produto pago só pra rodar em paralelo. Escolho Cypress quando o projeto é uma aplicação web pura em JavaScript ou TypeScript, o time já domina bem a ferramenta, a suíte é de porte médio, e a prioridade número um é a fluidez de depurar teste localmente enquanto ele ainda está sendo escrito.

O que eu não faço — e recomendo fortemente que você também não faça — é trocar de ferramenta só porque uma virou mais hype do que a outra. Migrar uma suíte de testes que já funciona, já está estável e já dá cobertura real custa tempo de reescrita, treinamento do time na sintaxe nova e o risco de introduzir bug no próprio conjunto de testes durante a transição — é um processo parecido, em espírito, com migrar de QA manual pra automação sem virar bagunça, só que dentro do próprio mundo automatizado. Se o Cypress já resolve seu problema hoje, o argumento pra trocar precisa ser mais forte do que “o Playwright está com mais menção no LinkedIn” — precisa ser uma limitação real que você já sentiu na pele.

Se você ainda está no começo dessa jornada e nem chegou no ponto de escolher entre as duas, vale saber que dá pra aprender qualquer uma delas sem gastar nada — já reuni sete cursos gratuitos de automação de testes que cobrem tanto Cypress quanto Playwright. E se a dúvida ainda for mais básica, entre continuar fazendo tudo manual ou dar o salto pra automação, o comparativo completo entre QA manual e automação de testes é o ponto de partida antes mesmo de pensar em qual ferramenta usar. Pra quem já testa API direto, sem depender do navegador, meu guia de testes de API mostra onde essas duas ferramentas se encaixam (ou não) nesse tipo de teste — e dominar bem qualquer uma delas é um dos passos mais concretos pra quem quer saber quanto tempo leva pra virar SDET.

Perguntas frequentes

Dá pra migrar de Cypress pra Playwright sem reescrever tudo?

Não sem esforço nenhum, mas também não é do zero. A lógica de negócio dos testes (o que testar, em que ordem, quais asserções fazem sentido) se aproveita quase inteira — o que muda é a sintaxe dos comandos e como você lida com seletores, espera e contexto de navegador. Times que já fizeram essa migração costumam levar de poucas semanas a alguns meses dependendo do tamanho da suíte, migrando arquivo por arquivo em vez de tentar trocar tudo de uma vez.

O Playwright substitui o Selenium?

Na prática, pra maioria dos casos de automação web, sim — o Playwright resolve boa parte das dores clássicas do Selenium (espera manual, instabilidade de driver, configuração complicada) com uma API mais moderna. Mas o Selenium ainda tem lugar em cenários bem específicos, como testes que dependem do WebDriver puro por exigência de compliance ou integração com ferramentas legadas que só falam esse protocolo.

Preciso saber TypeScript pra usar Playwright?

Não. Dá pra escrever testes em Playwright usando JavaScript puro, Python, Java ou C#, dependendo da linguagem que seu time já usa no dia a dia. TypeScript é recomendado pela comunidade porque a tipagem ajuda a pegar erro de seletor ou de asserção antes de rodar o teste, mas não é um requisito da ferramenta.

Cypress ou Playwright: qual dos dois é mais fácil pra quem está começando do zero?

Cypress costuma ter uma curva de entrada um pouco mais suave pra quem nunca escreveu teste automatizado, porque o runner interativo mostra visualmente o que está acontecendo a cada passo, o que ajuda a entender os conceitos antes de se preocupar com configuração. Isso não quer dizer que o Playwright seja difícil — o modo UI dele cobre boa parte dessa mesma necessidade — mas se o objetivo é o caminho com menos fricção no primeiro contato, o Cypress ainda leva uma pequena vantagem.