Cypress vs Selenium em 2026: o comparativo honesto (e o que ambos esquecem)

Em resumo

O teste automatizado de interface web consiste em executar cenários de verificação em uma aplicação web de forma programática, simulando ações do usuário para validar que a aplicação funciona conforme o esperado. Cypress e Selenium são os dois frameworks dominantes neste campo — mas cada um tem um ponto cego importante que ninguém quer reconhecer.

O debate Cypress vs Selenium é um clássico que ressurge todo ano, como «tabs vs spaces» ou «monolito vs microsserviços». Os artigos comparativos abundam. Mas a maioria se limita a listar diferenças técnicas sem tomar posição e, mais importante, sem abordar o elefante na sala: nem Cypress nem Selenium conseguem testar verdadeiramente o que seus usuários veem.

Este artigo é um comparativo opinativo. Você encontrará uma análise franca das forças e fraquezas de cada ferramenta, recomendações claras com base no seu contexto, e uma reflexão sobre o que ambas fundamentalmente deixam de lado.

Sumário

Selenium: o veterano que se recusa a morrer
Cypress: a ferramenta moderna que conquistou os desenvolvedores
As forças reais do Selenium em 2026
As forças reais do Cypress em 2026
As fraquezas que os defensores de cada campo minimizam
O grande esquecido: o teste visual
Nossa posição: escolha conforme sua necessidade, não conforme a moda
FAQ

Selenium: o veterano que se recusa a morrer

Selenium nasceu em 2004 na ThoughtWorks, o que lhe confere mais de 20 anos de existência. No mundo do software, essa é uma idade canônica. Muitos já o declararam morto — e muitos estavam errados.

Selenium WebDriver, a versão moderna do framework, é hoje a base do padrão W3C WebDriver. Isso é significativo: os navegadores Chrome, Firefox, Safari e Edge implementam nativamente o protocolo que o Selenium ajudou a definir. É um caso raro em que uma ferramenta open-source acaba moldando o próprio padrão web.

O projeto Selenium é ativamente mantido. A versão 4, lançada em 2021, trouxe suporte nativo ao Chrome DevTools Protocol (CDP), uma arquitetura modernizada e uma melhor gestão de grid distribuído. Em 2026, Selenium continua sendo o framework de teste mais implantado no mundo, com presença dominante em grandes empresas.

Cypress: a ferramenta moderna que conquistou os desenvolvedores

Cypress chegou ao cenário em 2017 com uma proposta radicalmente diferente: esqueça o WebDriver, vamos executar os testes diretamente no navegador.

Essa arquitetura «in-browser» não é um detalhe técnico — é o que explica praticamente todas as diferenças entre Cypress e Selenium. Como o Cypress executa no mesmo event loop da aplicação sob teste, ele tem acesso nativo ao DOM, às requisições de rede, aos timers e ao estado da aplicação. É por isso que é mais rápido, mais estável e mais fácil de depurar.

Em menos de 10 anos, Cypress conquistou a comunidade JavaScript. Segundo a pesquisa State of JS 2024, Cypress continua sendo a ferramenta de teste end-to-end mais utilizada no ecossistema JavaScript, à frente do Playwright (que está crescendo rapidamente). Sua experiência de desenvolvedor — o test runner interativo, o time-travel debugging, a documentação exemplar — estabeleceu um novo padrão para o que uma ferramenta de teste deveria ser.

As forças reais do Selenium em 2026

Cobertura multi-linguagem. Java, Python, C#, Ruby, JavaScript e Kotlin. Cobertura multi-navegador. Chrome, Firefox, Safari, Edge e IE. Ecossistema e maturidade. Mais de 20 anos de existência. Selenium Grid. Testes distribuídos em grande escala. Flexibilidade arquitetural. Sem imposição de opinião.

As forças reais do Cypress em 2026

Velocidade de execução. Cypress é significativamente mais rápido que Selenium para suítes de tamanho médio. A arquitetura in-browser elimina a latência do protocolo WebDriver. Os comandos Cypress são executados de forma síncrona no navegador, sem os round-trips de rede que tornam o Selenium mais lento.

Estabilidade dos testes. Testes flaky são o pesadelo de todo engenheiro de QA. Cypress reduz drasticamente esse problema com seu sistema de espera automática: cada comando aguarda até que o elemento esteja visível, interativo e estável antes de agir. Sem necessidade de espalhar sleeps arbitrários nos seus testes.

Experiência do desenvolvedor. O test runner do Cypress está numa categoria própria. Você vê seus testes serem executados em tempo real, pode fazer time-travel para ver o estado do DOM em cada passo, e as mensagens de erro são claras e acionáveis. Para um desenvolvedor, escrever testes com Cypress é quase prazeroso. Isso é raro.

Network stubbing nativo. Cypress pode interceptar e modificar requisições de rede diretamente no navegador. Isso é extremamente poderoso para testar casos extremos (API lenta, erro 500, resposta vazia) sem configurar um servidor mock externo.

Documentação. A documentação do Cypress é, sem exagero, uma das melhores da indústria open-source. Cada conceito é claramente explicado, com exemplos funcionais e guias de migração. É uma vantagem competitiva frequentemente subestimada.

As fraquezas que os defensores de cada campo minimizam

As fraquezas do Selenium que ninguém quer ver

Complexidade de configuração. Configurar um ambiente Selenium funcional — WebDriver, drivers de navegador, grid, relatórios — continua sendo tedioso. Em 2026, ainda é um investimento significativo, mesmo com Docker e ferramentas de conteinerização.

Fragilidade dos testes. Os testes Selenium são notoriamente frágeis. Uma mudança menor no DOM (um atributo que muda, um elemento que carrega um milissegundo mais tarde) pode quebrar uma suíte inteira de testes. As equipes gastam um tempo considerável mantendo testes em vez de escrever novos.

Lentidão relativa. O protocolo WebDriver introduz uma latência incompressível. Para uma suíte de 1.000 testes, essa latência acumulada é significativa. O Selenium Grid mitiga o problema por meio de paralelização, mas adiciona complexidade de infraestrutura.

As fraquezas do Cypress que ninguém quer ver

Apenas JavaScript. Cypress suporta apenas JavaScript (e TypeScript). Se suas equipes de teste trabalham em Java ou Python, migrar para Cypress significa uma mudança completa de linguagem. Isso não é um detalhe.

Limitações multi-aba e multi-domínio. Cypress historicamente teve limitações para cenários envolvendo múltiplas abas ou múltiplos domínios. Melhorias foram feitas (cy.origin), mas alguns cenários complexos continuam mais naturais com Selenium.

Dependência de um editor comercial. Cypress é open-source, mas Cypress.io (agora parte do ecossistema Cloud) oferece serviços pagos (Cypress Cloud) para dashboard, paralelização e analytics. O modelo open-core cria uma dependência que algumas organizações preferem evitar.

Cobertura de navegadores limitada. Cypress suporta Chrome, Edge, Firefox e navegadores baseados em Chromium. Safari não é suportado nativamente. Para organizações que precisam testar no Safari (e-commerce B2C, por exemplo), essa é uma limitação real.

O grande esquecido: o teste visual

Cypress e Selenium são ferramentas de teste funcional. Verificam que sua aplicação se comporta corretamente. Respondem a: "Funciona?"

Cypress e Selenium são ferramentas de teste funcional. Eles verificam que sua aplicação se comporta corretamente: clicar neste botão leva a aquela página, este formulário exibe aquela mensagem de erro, esta API retorna aqueles dados. Eles respondem à pergunta: «Funciona?»

Mas não respondem à pergunta: «Parece como deveria?»

Um teste Cypress que verifica que o botão «Adicionar ao carrinho» está presente e clicável nunca vai dizer que esse botão passou de verde para cinza porque um arquivo CSS foi mal mesclado. Um teste Selenium que valida o fluxo de pagamento não vai detectar que o formulário de cartão de crédito se sobrepõe ao resumo do pedido no mobile.

Esses bugs visuais são invisíveis para os testes funcionais. E são a primeira coisa que seus usuários notam.

Plugins de teste visual: uma resposta insuficiente

Sim, Cypress tem plugins de teste visual. Sim, Selenium pode ser combinado com bibliotecas de comparação de imagens. Mas vamos ser honestos sobre as limitações:

Manutenção pesada. Esses plugins são complementos, não funcionalidades nativas. Eles adicionam complexidade à sua suíte de testes, exigem configuração específica e introduzem dependências adicionais para manter.

O workflow é técnico. Para usar um plugin de teste visual no Cypress ou Selenium, você precisa escrever código. Isso exclui designers, product owners e QAs não técnicos — exatamente as pessoas mais bem posicionadas para julgar se uma interface «parece como deveria».

Gestão de baselines é primitiva. Os plugins de teste visual para Cypress e Selenium tipicamente armazenam baselines no repositório Git, sem workflow de aprovação, sem histórico visual utilizável e sem dashboard dedicado.

Falsos positivos são endêmicos. Sem limiares de tolerância granulares, zonas de exclusão e gestão de anti-aliasing, os plugins de teste visual geram um volume de falsos positivos que rapidamente desencoraja as equipes.

A solução: uma ferramenta dedicada

Nossa posição é clara: para teste visual, use uma ferramenta dedicada. Não um plugin, não um add-on, não um hack. Uma ferramenta cujo único propósito é o teste visual.

Uma ferramenta dedicada de teste visual oferece o que os plugins não conseguem: uma interface de revisão visual projetada para comparação de imagens, gestão de baselines com workflows de aprovação, limiares de tolerância inteligentes que reduzem falsos positivos, e acessibilidade para perfis não técnicos.

É exatamente isso que o Delta-QA faz: teste visual, e nada mais. Sem scripts para escrever, sem framework para configurar, sem dependências para manter. Você compara visualmente suas páginas, detecta regressões e aprova mudanças intencionais. É simples assim.

Nossa posição: escolha conforme sua necessidade, não conforme o hype

O debate Cypress vs Selenium é um falso dilema para muitas equipes, porque faz a pergunta errada. A pergunta real não é «qual é a melhor ferramenta?» — é «qual é a melhor ferramenta para o meu contexto?»

Escolha Selenium se sua organização usa múltiplas linguagens de programação, se você precisa de cobertura Safari nativa, se já tem um investimento significativo no ecossistema Selenium, ou se precisa do Selenium Grid para testes distribuídos em grande escala.

Escolha Cypress se seu stack é JavaScript/TypeScript, se a experiência do desenvolvedor é prioridade, se você precisa de testes rápidos e estáveis, e se seus cenários não exigem tratamento complexo de multi-aba ou multi-domínio.

E em ambos os casos, adicione uma ferramenta dedicada de teste visual. Nem Cypress nem Selenium cobre esse ângulo, e é o ângulo que seus usuários notam primeiro.

Perguntas Frequentes

O Playwright não tornou esse debate obsoleto?

Playwright é de fato um concorrente sério que merece lugar na discussão. Desenvolvido pela Microsoft, combina certas forças do Selenium (multi-browser, multilíngue) e do Cypress (arquitetura moderna, auto-wait). Porém, em 2026, Cypress e Selenium ainda dominam em termos de base instalada e ecossistema. O Playwright está crescendo rapidamente, mas ainda não tornou os outros dois obsoletos — ele adicionou uma terceira opção.

É possível usar Cypress e Selenium juntos no mesmo projeto?

Tecnicamente sim, mas raramente é uma boa ideia. Manter dois frameworks de teste significa duas configurações, dois conjuntos de boas práticas e duas curvas de aprendizado. Se você está migrando de Selenium para Cypress, faça de forma progressiva por módulo em vez de manter ambos indefinidamente.

Cypress vs Selenium: qual é mais rápido em 2026?

Para suítes de tamanho médio (algumas centenas de testes), Cypress geralmente é mais rápido graças à sua arquitetura in-browser. Para suítes muito grandes (milhares de testes), o Selenium Grid com paralelização massiva pode ser competitivo. A resposta depende do seu volume e da sua infraestrutura.

O teste visual pode substituir os testes funcionais do Cypress ou Selenium?

Não. O teste visual e o teste funcional cobrem ângulos diferentes. O teste funcional verifica o comportamento (funciona?), o teste visual verifica a aparência (parece como deveria?). Um botão pode estar visualmente correto mas não funcional ao clicar, e vice-versa. Ambos são necessários para uma cobertura completa.

Qual é o custo real de migrar de Selenium para Cypress?

O custo depende do tamanho da sua suíte de testes existente, da linguagem utilizada (se você está em Java, a migração envolve uma mudança de linguagem) e da complexidade dos cenários. Para uma suíte de 500 testes Selenium em JavaScript, planeje de 2 a 4 meses para uma equipe de 2-3 pessoas. O custo principal não é reescrever os testes — é adaptar padrões e práticas.

Por que Delta-QA em vez de um plugin de teste visual para Cypress?

Um plugin de teste visual no Cypress te condiciona ao workflow técnico do Cypress: você precisa escrever código, executar testes no pipeline e gerenciar baselines no Git. O Delta-QA é uma ferramenta autônoma acessível a toda a equipe — designers, PMs, QAs não técnicos — com uma interface dedicada de comparação visual, workflows de aprovação e gestão granular de tolerâncias. Para teste funcional, use Cypress ou Selenium. Para teste visual, use uma ferramenta construída para esse propósito.

Para aprofundar

Conclusão: a ferramenta certa no lugar certo

Cypress e Selenium são duas excelentes ferramentas de teste funcional. A escolha entre eles depende do seu stack, da sua equipe e das suas restrições — não de um ranking abstrato.

Mas seja qual for sua escolha, você terá um ponto cego: o teste visual. Nem Cypress nem Selenium foi projetado para detectar regressões visuais, e os plugins que tentam preencher essa lacuna continuam sendo soluções de compromisso.

Para teste visual, você merece uma ferramenta dedicada. Uma ferramenta que faz uma coisa, e faz bem.

Experimentar o Delta-QA Gratuitamente →