De Cypress para Playwright: o que aprendi migrando uma suíte E2E real

Uma perspectiva de QA sobre performance, BDD e o que ninguém te conta antes de migrar

Quando comecei a trabalhar com testes automatizados, o Cypress era minha ferramenta principal. Funciona bem, tem uma curva de aprendizado gentil, e a comunidade é enorme. Por um bom tempo, não tinha razão pra questionar isso.

Mas projetos crescem. Suítes crescem. E o que funcionava bem num contexto menor começou a mostrar sinais de cansaço: tempos de execução altos, waits espalhados pelo código, e uma sensação constante de que os testes eram mais lentos do que precisavam ser. Foi aí que a migração para o Playwright entrou em cena mas não por modismo, mas por necessidade real.

Por que migrar?

A decisão não foi imediata. Antes de qualquer movimento, fizemos um diagnóstico: medimos o baseline de cada spec, identificamos gargalos, e só então colocamos as opções na mesa.

O Cypress tem muita coisa boa o auto-waiting, seletores intuitivos, uma UI de debug que é genuinamente boa de usar. Mas algumas limitações pesaram na decisão:

O paralelismo no Cypress existe, mas só no plano pago via Cypress Cloud. Localmente e em CI sem a plataforma deles, você roda os testes em sequência. O Playwright tem paralelismo nativo, de graça, com controle fino por workers e projetos.

Os waits automáticos do Cypress são bons, mas têm um teto. Em fluxos com comportamento assíncrono mais complexo — debounce, estados intermediários, requests encadeadas onde você ainda acaba colocando cy.wait() fixo pra compensar. O Playwright espera o estado real do elemento, o que elimina boa parte desses casos.

A performance em si também é diferente. Nos nossos testes, o Playwright foi consistentemente mais rápido onde no fluxo de login chegamos a 36% de diferença. Em uma suíte com dezenas de cenários em CI, isso representa minutos economizados por pipeline.

O que é BDD e por que vale a pena

BDD — Behavior Driven Development — é uma abordagem onde os testes são escritos em linguagem próxima do negócio, usando uma sintaxe chamada Gherkin:

Dado que estou na tela de login
Quando preencho minhas credenciais
Então devo acessar o dashboard

A ideia não é só técnica. É sobre comunicação. Um cenário escrito assim pode ser lido e validado por qualquer pessoa do time, considerando nosso cenário de um ecossitema de dev, PO, QA, stakeholder. O teste vira documentação viva do comportamento esperado do sistema.

Com a lib playwright-bdd, você conecta esses cenários diretamente ao Playwright. O .feature file descreve o comportamento, os steps implementam a interação com a tela, e as pages encapsulam os seletores e ações de cada módulo.

O que a migração me ensinou

Entender antes de migrar. O maior erro que se pode cometer é pegar um teste do Cypress e tentar traduzir linha por linha. Os dois frameworks têm filosofias diferentes. Antes de migrar qualquer fluxo, eu precisava entender o que o teste estava validando de verdade e não apenas o que ele estava fazendo.

O front é a fonte da verdade. Várias vezes durante a migração um teste falhava de forma inesperada. A solução quase sempre estava em entender como o componente realmente se comportava, qual evento ele esperava, qual estado ele precisava estar, qual request estava sendo feita. Ler o código do front virou parte do processo.

Flakiness tem causa raiz. Testes instáveis existem por algum motivo. Aumentar timeout é um curativo. A migração foi uma oportunidade de investigar de verdade onde descobri que boa parte da instabilidade vinha de waits que mascaravam comportamento assíncrono real da aplicação.

Page Object não é burocracia. No começo parece overhead criar uma classe separada só pra encapsular interações com uma tela. Mas quando você tem cinco módulos e precisa ajustar um seletor, você agradece ter feito isso desde o início.

Resultados aparecem rápido. Já nas primeiras ondas de otimização conseguimos reduzir o tempo de execução de uma das suítes em quase 50%. Isso muda a conversa sobre testes automatizados dentro do time assim eles deixam de ser “aquela coisa que demora” e passam a fazer parte natural do fluxo.

O que vem pela frente

A migração ainda está em andamento. Alguns módulos já estão rodando em Playwright, outros ainda em Cypress. A estratégia foi migrar por fluxo e assim validar cada parte antes de avançar em vez de tentar fazer tudo de uma vez.

Em paralelo, estou começando a aplicar o mesmo setup em um novo projeto. Cada vez que repito o processo, fica mais claro o que é essencial desde o início: uma boa estrutura de fixtures, autenticação salva em storageState, e cenários BDD que descrevem comportamento real, não cliques.

Pra quem está pensando em migrar

Não comece pela ferramenta. Comece pela pergunta: o que está incomodando na suíte atual? Se for performance, instabilidade ou manutenabilidade o Playwright provavelmente resolve. Se tudo estiver funcionando bem, talvez não valha o esforço agora.

Mas se você decidir migrar: vai devagar, valida cada etapa, e leia o código do front. Você vai precisar.