Resumo. No contexto do desenvolvimento de software em métodos ágeis, ter um feedback rápido e contínuo é crucial para o sucesso dos projetos. Uma das formas de garantir a detecção rápida de bugs é através da execução de testes automatizados. Dado o alto valor dos testes automatizados, é necessário avaliar os vários frameworks disponíveis no mercado atualmente para determinar qual deles melhor se adequa às necessidades do projeto. Neste trabalho, é proposta uma análise comparativa entre três frameworks de testes: Selenium, uma das ferramentas de automação mais tradicionais; Cypress, uma ferramenta que ganhou bastante popularidade nos últimos anos; e Playwright, uma ferramenta mais recente que tem atraído bastante atenção. Para realizar essa análise, foram desenvolvidas suítes de testes automatizados para uma aplicação web, com o objetivo de comparar os scripts gerados com base em critérios selecionados. Dessa forma, serão apresentados os prós e contras de trabalhar com cada um desses frameworks.
Os testes de software, entre outros objetivos, buscam detectar falhas e defeitos existentes com o intuito de reduzir os níveis de risco de qualidade de software [ISTQB-CTFL]. A Regra 10 de Myers estabelece que o custo de correção de defeitos tende a aumentar quanto mais tarde o defeito é detectado. Defeitos encontrados durante a produção tendem a custar muito mais que defeitos encontrados em modelos de dados e em outros documentos do projeto do software. Dessa forma, ao tratar os testes como um processo organizado e muitas vezes paralelo e integrado ao processo de desenvolvimento, os custos de manutenção serão reduzidos. [Bastos 2007]
Nos dias atuais, muitas opções de softwares estão sendo lançadas constantemente de forma que o custo de se trocar de software não é mais tão alto quanto antigamente. Por esse motivo, a adoção de métodos ágeis para desenvolvimento está cada vez mais comum, para atender as necessidades dos clientes com incrementos constantes e correções rápidas. Em razão disso, o prazo de lançamento de uma aplicação se torna cada vez mais curto e consequentemente o tempo disponível para execução de teste se torna cada vez menor.
Em razão do tempo menor para desenvolver e lançar um aplicativo, os testes automáticos se tornam necessários para encontrar defeitos e garantir qualidade durante os ciclos de desenvolvimento. A automação de teste é o uso de software para controlar a execução de testes de software através da aplicação de estratégias e ferramentas, comparando os resultados esperados com os resultados reais. Seus objetivos são a redução do envolvimento humano em atividades manuais, de tempo demandado e de custo final. [Oliveira 2018]
Atualmente, existem muitas opções de frameworks para automação de testes, muitos deles de código aberto , mas, mesmo a seleção de um framework de código aberto para adesão na empresa não está livre de custo, afinal, deve-se levar em conta a curva de aprendizado de um framework, que vai afetar no tempo necessário de treinamento de um funcionário para aprender como utilizar. Ao lado disso, é preciso verificar se o framework atende todas as necessidades de utilização, pois, do contrário, será necessário modificá-lo por meio de customizações ou instalação de plugins de terceiros. Esses fatores tornam a escolha de um framework uma tarefa complexa, sendo necessária uma boa análise.
Um dos frameworks mais tradicionais e amplamente conhecidos é o Selenium, projeto abrangente para uma variedade de ferramentas e bibliotecas que permitem e suportam a automação de navegadores web [Selenium 2023a]. Apesar de sua primeira versão ter sido criada em 2004, o framework está atualmente em sua versão 4.0 e conta com um grande suporte da comunidade, como pode ser visto na Tabela 1 [Selenium 2024a].
| Framework | Linguagens suportadas | Cópias no GitHub | Estrelas no GitHub |
|---|---|---|---|
| Selenium | Java, Javascript, Python, Ruby, C# | 7.9K | 29K |
Tabela 1. Dados sobre o framework Selenium
O Cypress é uma ferramenta recente para testes front-end construída para aplicações web modernas. Pode-se realçar que há, nela, a abordagem dos principais pontos de dor enfrentados pelos desenvolvedores e engenheiros de QA ao testar aplicações modernas [Cypress 2024a]. Apesar de ter sido criado em 2017, o Cypress possui um alto número de usuários ativos atualmente, tal como indica a Tabela 2. [Cypress 2024b]
| Framework | Linguagens suportadas | Cópias no GitHub | Estrelas no GitHub |
|---|---|---|---|
| Cypress | Javascript | 3.1K | 45.9K |
Tabela 2. Dados sobre o framework Cypress
O Playwright foi criado especificamente para atender às necessidades de testes de ponta a ponta. Capaz de suportar todos os motores de renderização modernos, incluindo Chromium, WebKit e Firefox [Playwright 2024a], foi concebido em 2020, pela Microsoft, vem chamando bastante atenção da comunidade, como pode ser verificado na Tabela 3 [Playwright 2024b].
| Framework | Linguagens suportadas | Cópias no GitHub | Estrelas no GitHub |
|---|---|---|---|
| Playwright | Java, Javascript, Python, C# | 3.2K | 60.1K |
Tabela 3. Dados sobre o framework Playwright
Embora seja mais recente, o Playwright já superou o Selenium em número de downloads e apesar de ter diminuído a distância do Cypress no último ano, ainda está distante do número de downloads do Cypress, situação indicada na Figura 1.
Figura 1. Quantidade de downloads de cada framework nos últimos 5 anos. [NPM Trends 2024]
Assim sendo, diante do exposto até então, este trabalho tem como objetivo identificar as principais funcionalidades e limitações dos frameworks selecionados, realizar as configurações de ambiente, elaborar a arquitetura do projeto de automação, de modo a seguir as boas práticas de engenharia de software, desenvolver os mesmos scripts de teste em cada framework, executar e validar para comparar os resultados obtidos posteriormente.
O Selenium é uma coleção de diferentes ferramentas para automação que permite testar aplicações no browser. Lançado em 2004, foi criado pela Thoughtworks, tendo como seus principais componentes o Selenium Grid, Selenium IDE, Selenium RC e Selenium Webdriver. Tem suporte aos principais browsers existentes no mercado, como o Chrome, Firefox, Safari, Internet Explorer, Edge, Opera, entre outros. Seus scripts são compatíveis com Javascript, Java, Ruby, C# e Python. [Akhtar 2023]
Por ter sido desenvolvido inicialmente em uma época em que os browsers eram bem mais simples, em relação ao que são hoje, uma das reclamações comuns é a de que o Selenium costuma ser mais lento se comparado a frameworks mais novos [Raggo 2023]. Ao lado disso, costuma ser mais instável, em razão da presença de testes flake pela necessidade de se incluir esperas implícitas ou explícitas no script. [Pathak 2023]
O Cypress, diferentemente da grande maioria das ferramentas de automação, não foi desenvolvido com base no Selenium e, por esse motivo, não é limitado por suas capacidades. É focado nos testes de ponta a ponta e seus scripts de teste são escritos apenas em Javascript. Nota-se, então, que o Cypress é uma suíte de teste completa com seu próprio executor e relatórios. Suporta browsers como Firefox e todos que são baseados no Chromium, como Chrome, Edge e Electron. A ferramenta vem com a habilidade de gravar vídeos e fazer capturas de telas durante a execução de testes [Döring and Brueckner 2022].
O Cypress tem seu melhor desempenho em testes locais, mas pode não ser a opção mais rápida para executar testes em sites ativos, e, pelo seu alto tempo de inicialização, pode interferir em cenários de monitoramento de alta frequência, mas provavelmente não fará diferença real no contexto das compilações clássicas de teste E2E [Raggo 2024].
O Playwright, assim como o Cypress, não foi construído com base no Selenium e é uma solução completamente independente. Oferece suporte a todos os principais browsers e diferentes linguagens de programação, como Java, Javascript e Python. Ao lado disso, fornece a alternativa de capturas de tela, vídeos e rastreamento de execução com suporte imediato. Vem com o próprio executor de teste, mas pode utilizar outro de escolha do usuário. Também permite executar testes em várias guias, origens e usuários no mesmo teste [Döring; Brueckner 2022].
O Playwright oferece suporte a testes de API, mas não a desativação de redirecionamentos, assim como emula dispositivos móveis com o emprego de navegadores de desktop no lugar de dispositivos reais. [Akhtar 2023]
Os trabalhos Puppeteer vs Selenium vs Playwright, a speed comparison [Raggo 2023], Cypress vs Selenium vs Playwright vs Puppeteer speed comparison [Raggo 2024], Why we favor Playwright over Selenium or Cypress [Döring and Brueckner 2022], Cypress vs Selenium vs Playwright vs Puppeteer: Core Differences [Akhtar 2023], Playwright vs Selenium vs Cypress: A Detailed Comparison [Pathak 2023] e Automação de testes funcionais para aplicações web: comparativo dos frameworks Cypress e Playwright [França 2023] realizam estudos semelhantes aos apresentados aqui, em relação a comparação do Selenium, Cypress e Playwright.
As métricas utilizadas nos trabalhos citados são similares às utilizadas neste estudo. Assim sendo, cita-se a comparação do tempo de codificação e execução dos scripts; a análise do suporte a diferentes linguagens de programação e browsers, a facilidade de se realizar o setup inicial do projeto; a necessidade de instalação de bibliotecas externas para realizar a captura de telas e vídeos; a arquitetura na qual foi construída; a capacidade de integração com ferramentas de CI/CD, e, por fim, suporte para testes de API e aparelhos móveis.
O experimento executado neste trabalho será realizado automatizando a mesma suíte de testes do site Sauce Demo nos diferentes frameworks, utilizando a linguagem Javascript e o padrão Page Objects, de forma a garantir que o uso de uma linguagem diferente possa influenciar no tempo de execução dos testes. No entanto, verifica-se que, nas pesquisas que inspiraram este estudo, também é avaliado o Puppeteer1, o que, aqui, foi desconsiderado, pois é muito parecido com o Playwright.
O site Sauce Demo (http://www.saucedemo.com), criado com o intuito de praticar a automação de testes, foi utilizado como exemplo de aplicação web, graças à possibilidade de se criar cenários de testes E2E.
No presente estudo, foi realizado um experimento, em que os frameworks Selenium, Cypress e Playwright foram estudados e uma suíte de testes automatizados foi implementada utilizando cada um deles. A elaboração dessas suítes possui o intuito de identificar as principais características de cada framework durante o processo de desenvolvimento dos scripts de teste, o que possibilita a identificação dos prós e contras de cada framework.
Para um comparativo efetivo, é necessário que algumas métricas sejam definidas para que sejam analisadas com o intuito de avaliar e identificar as diferenças entre os frameworks, de forma a entender quais são seus pontos fortes e fracos. As métricas utilizadas na análise foram:
- Facilidade para realizar o setup inicial do projeto e necessidade de instalação de bibliotecas externas;
- Arquitetura do framework;
- Tempo gasto codificando o projeto de automação;
- Tempo de execução dos scripts de teste;
O site Sauce Demo (https://www.saucedemo.com/), utilizado para realizar o comparativo da automação, é uma aplicação web simples, que permite a execução de um fluxo E2E que simula a compra de produtos em um site de e-commerce. Para tanto, foram criados uma suíte completa com 23 casos de testes de todas as funcionalidades do site para comparar o desempenho com uma suíte de testes mais completa, visto que, com apenas um caso de teste, diferenças de desempenho que possam surgir em um número maior de testes poderiam ser perdidas. Os scripts de teste criados para a análise podem ser verificados na Tabela 4.
| Feature | Caso de Teste | Objetivo do Teste |
|---|---|---|
| Login | CT01 - Realizar login com usuário standard | Verificar que o login acontece corretamente na aplicação com um usuário padrão. |
| Login | CT02 - Realizar login com usuário bloqueado | Verificar que é exibido uma mensagem de erro impedindo o login do usuário bloqueado. |
| Login | CT03 - Realizar login com usuário com problema | Verificar que uma versão do site em que todas as imagens dos produtos estão incorretas é apresentada ao logar com um usuário com problemas. |
| Login | CT04 - Realizar login com erros de performance | Verificar que o login é realizado com lentidão ao utilizar um usuário com erros de performance. |
| Login | CT05 - Realizar login com erro de layout | Verificar que uma versão do site em que alguns produtos estão com a imagem fora do tamanho padrão é apresentada ao logar com um usuário com erro de layout. |
| Products | CT06 - Inserir produto no carrinho e validar que foi gravado corretamente no carrinho | Validar que o produto pode ser inserido no carrinho através da página de lista de produtos. |
| Products | CT07 - Remover produto do carrinho pela página de produto | Validar que o produto pode ser removido do carrinho através da página de lista de produtos. |
| Products | CT08 - Adicionar produto no carrinho pela página do produto e verificar que gravou corretamente no carrinho | Validar que o produto pode ser inserido no carrinho através da página de detalhe do produto. |
| Products | CT09 - Remover produto do carrinho pela página do produto e voltar a página de produtos | Validar que o produto pode ser removido do carrinho através da página de detalhe do produto e voltar a página de lista de produtos. |
| Products | CT10 - Validar adicionar e remover todos os produtos no carrinho | Validar que todos os botões de adicionar e remover da página de lista de produtos estão funcionando corretamente. |
| Products | CT11 - Validar ordenação padrão em ordem alfabética crescente | Validar que a ordenação padrão em ordem alfabética crescente é apresentada ao acessar a página de lista de produtos. |
| Products | CT12 - Ordenar produtos em ordem alfabética decrescente | Validar que ao alterar a ordenação da página de lista de produtos para ordem alfabética decrescente os produtos são apresentados corretamente. |
| Products | CT13 - Ordenar produtos em preço do menor para o maior | Validar que ao alterar a ordenação da página de lista de produtos para ordem por preço do menor para o maior os produtos são apresentados corretamente. |
| Products | CT14 - Ordenar produtos em preço do maior para o menor | Validar que ao alterar a ordenação da página de lista de produtos para ordem por preço do maior para o menor os produtos são apresentados corretamente. |
| Your Cart | CT15 - Validar botão continuar comprando | Validar que o botão continuar comprando redireciona de volta para a página de lista de produtos. |
| Your Cart | CT16 - Validar botão remover produto | Validar que o botão remover produto exclui o produto do carrinho. |
| Your Cart | CT17 - Validar botão checkout | Validar que o botão checkout redireciona para a página de informações do checkout. |
| Checkout Your Information | CT18 - Clicar botão cancelar deve retornar ao carrinho e não salva as informações | Validar que ao clicar no botão cancelar as informações digitadas não são salvas. |
| Checkout Your Information | CT19 - Validar preencher os campos de texto e clicar em continuar | Validar que ao clicar no botão continuar as informações digitadas são salvas. |
| Checkout Your Information | CT20 - Validar obrigatoriedade dos campos de texto | Validar que ao clicar no botão continuar são apresentadas validações dos campos obrigatórios. |
| Checkout Overview | CT21 - Botão cancelar deve voltar para a página de produtos | Validar que ao clicar no botão cancelar está redirecionando o usuário para a página de lista de produtos. |
| Checkout Overview | CT22 - Botão continuar deve finalizar o pedido | Validar que ao clicar no botão continuar é realizado a finalização do pedido e será redirecionado para a página com a mensagem de sucesso. |
| Checkout Complete | CT23 - Clicar no botão voltar para home deve voltar a página de produtos | Validar que ao clicar no botão Back Home na página de finalização do pedido será redirecionado para a página de lista de produtos. |
Tabela 4. Casos de Teste Automatizados
Para fins de realizar uma análise sem discrepâncias, em razão de qualquer divergência nos ambientes de execução, todas as suítes de testes foram executadas localmente em um único equipamento. Abaixo, pode-se ler as seguintes configurações da máquina:
- Computador: Samsung Expert X50 NP350XBE-XH3BR
- Processador: QuadCore Intel Core i7-8565U, 4050 MHz (42x96)
- Memória: 20 GB 2667 MHz DDR4
- Placa gráfica: NVIDIA GeForce MX110 2048MB
- Sistema Operacional: Microsoft Windows 11 Home Single Language
- Navegador: Google Chrome
O estudo foi iniciado na instalação e configuração do framework Cypress, o que se mostrou bem simples. O único pré-requisito solicitado pelo Cypress é a presença do Node.js instalado na máquina de trabalho onde o projeto de automação será instalado e configurado.
Sequencialmente, foram utilizados os comandos "npm init" para iniciar o projeto e "npm install cypress" para instalar as dependências do Cypress, o que deixou o arquivo package.json, conforme pode ser visto na Figura 2.
Figura 2. Arquivo package.json do projeto poc_cypress.
Não foram necessárias instalações de dependências adicionais para o projeto Cypress, uma vez que o framework já possui suas próprias bibliotecas de teste, relatórios, assertividade, sem a necessidade de fazer configurações para capturas de fotos ou vídeos nas execuções dos testes por ser um recurso nativo do Cypress.
A configuração inicial do projeto também é facilitada ao executar o comando "npx cypress open" que abre o runner do Cypress e cria a estrutura básica das pastas na primeira execução. O projeto foi disponibilizado publicamente no GitHub https://github.com/AndradeTC86/poc_cypress
Posteriormente, foi iniciado a instalação e configuração do Playwright, que também foi bem simples e tinha como único pré-requisito o Node.js na estação de trabalho. Após a criação do diretório, foi executado o comando "npm init playwright@latest" que realizou a instalação do framework com algumas perguntas sobre a configuração do projeto. De início, foi perguntado qual seria a linguagem de programação utilizada (Javascript ou Typescript), qual seria o nome da pasta onde seriam armazenados os scripts de testes, se já desejaria a instalação do fluxo do Github Actions e, por último, se desejaria instalar os browsers suportados pelo Playwright.
Após selecionar as opções desejadas, também foi instalado uma dependência adicional @types/node para contornar as dificuldades do Javascript com as definições de tipos das bibliotecas do Node, como, por exemplo, para utilizar o require para importar páginas e comandos customizados. Ao final da instalação, o package.json ficou conforme a Figura 3.
Figura 3. Arquivo package.json do projeto poc_playwright.
Não houve necessidade de instalação de bibliotecas adicionais porque o Playwright possui suporte nativo para teste, relatórios, capturas de tela e assertividade, mas, ainda assim, possui suporte para integração com diversos outros frameworks de teste.
Em relação a organização do projeto, apenas a pasta previamente estabelecida para os scripts de testes foi criada, sendo necessário elaborar a estrutura das demais pastas, o que pode ser uma complicação para alguém com menos experiência em automação de testes.
O Playwright nativamente executa os testes no modo headless, nos browsers instalados disponíveis na máquina local e paralelamente em uma quantidade de sessões de acordo com a capacidade de memória e do processador. Na minha máquina local, eram utilizados até quatro sessões simultâneas. Por padrão, caso ocorra algum erro em um teste o Playwright, cria-se um relatório de falhas automaticamente; caso todos os testes passem, o relatório não é aberto automaticamente, mas pode ser visualizado com o comando "npx playwright show-report". Este projeto está acessível publicamente no GitHub https://github.com/AndradeTC86/poc_playwright
O último framework instalado foi o Selenium, que demandou mais configurações iniciais. Ele não possui pré-requisitos, podendo ser configurado em projetos que utilizam qualquer uma das linguagens de programação suportadas. Como o projeto de automação foi criado a partir da mesma linguagem usada nos outros projetos, emprega-se o Node.js como base de instalação.
Foi utilizado o comando "npm install selenium" para instalar o framework. Como não possui suporte nativo, foi necessário instalar dependências adicionais, como Axios, para realizar requisições em API, para verificar o tempo de resposta da requisição do login; Chai para as bibliotecas de assertividade e Mocha; o framework para execução dos testes, o que demandou trocar as extensões dos arquivos de .js para .mjs, condição que deixou o arquivo package.json conforme pode ser visto na Figura 4.
Figura 4. Arquivo package.json do projeto poc_selenium.
Toda a organização das pastas do projeto precisou ser criada manualmente, sem ajuda do framework para tal tarefa.
A nova versão do Selenium fez uma melhoria na configuração para realizar o download automático dos drivers de acordo com o browser a ser utilizado, o que facilitou bastante em relação a versões anteriores, nas quais era necessário salvar a versão do driver desejado em um diretório no local de instalação do projeto, com o intuito de executar os testes. Esse projeto está disponível publicamente no GitHub https://github.com/AndradeTC86/poc_selenium
Dentre os frameworks avaliados, o Cypress se mostrou o mais fácil de ser instalado, por não precisar de dependências externas e pela configuração automática das pastas na primeira execução.
O Playwright também foi bem simples de instalar, sem dependências e com a configuração base sendo criada após a execução do comando.
Nesse quesito, o Selenium foi o mais difícil de ser instalado, necessitando de bibliotecas de dependências externas e com toda a configuração inicial sendo feita a mão.
Cypress é um framework de teste utilizado para automação de aplicações web. Ele possui uma arquitetura única designada para executar os testes de maneira rápida e confiável. No teste da interface de usuário, todos os comandos são executados diretamente no browser sem dependência de nenhum driver. Como a execução dos testes é realizada diretamente no browser, ela se torna mais rápida sem interferência da velocidade da rede. A Figura 5 apresenta uma visualização da arquitetura do Cypress.
Figura 5. Arquitetura do Cypress. [Tutorials Point 2020]
Há um servidor Node por trás do Cypress, e o processo do Node se comunica, sincroniza e executa tarefas constantemente em prol um do outro. O servidor Node e o browser se comunicam através do WebSocket, que inicia assim que o proxy é criado. Por causa dessa forma de executar os testes dentro do browser, torna-se mais fácil trabalhar diretamente com a DOM2, a camada de rede e o armazenamento local. Por essa facilidade de acesso com o Cypress, torna-se vantajoso na execução dos testes em comparação com outros frameworks. [Pathak 2023]
O Playwright trabalha diretamente com o WebSocket, o que significa que assim que o teste é iniciado, o código é convertido para o formato JSON e enviado ao servidor com o protocolo do WebSocket. Quando a conexão é estabelecida, comandos são enviados entre o teste e o servidor do Playwright. A arquitetura do Playwright é apresentada na Figura 6.
Figura 6. Arquitetura do Playwright [Learn Microsoft 2023]
As conexões entre o cliente e servidor permanecem ativas até que uma ou ambas as partes envolvidas as descontinuem. Após fechar a conexão, ela é encerrada nas duas pontas. Um dos motivos pelo qual o Playwright é rápido é porque a conexão permanece ativa enquanto nenhuma das partes a encerra. [Pathak 2023]
Selenium é um framework de teste de código aberto usado para automação de testes web. O protocolo JSON Wire foi removido no Selenium 4 em favor do WebDriver W3C, que, agora, é o padrão oficial para controlar navegadores da web. No entanto, a equipe do Selenium ainda fornece suporte ao protocolo desatualizado.
O novo protocolo, chamado WebDriver W3C, recebeu a aceitação do “World Wide Web Consortium” (W3C). Na arquitetura do Selenium 4, podemos ver a comunicação direta entre o cliente e servidor sem precisar do protocolo JSON Wire. O mesmo protocolo é usado pelo Selenium WebDriver e navegadores da web, o que torna a execução do caso de teste rápida e a instabilidade extremamente baixa. Podemos ver um exemplo da arquitetura do Selenium na Figura 7.
Figura 7. Arquitetura do Selenium [Pathak 2023]
Existem muitos benefícios em adotar o protocolo WebDriver W3C, que é mais rico em comparação com o JSON Wire. Destacamos que a API de ações foi reformulada para funcionar com a especificação do WebDriver e agora permite que você execute ações multitoque, aumentar ou diminuir o zoom, pressionar duas teclas simultaneamente e muito mais [Pathak 2023].
A arquitetura do Playwright demonstrou ser a mais moderna dentre as avaliadas, sendo uma opção muito boa, mantendo a conexão ativa durante a execução dos testes, proporcionando uma velocidade maior na execução dos testes com uma complexidade um pouco maior.
A arquitetura do Cypress por executar diretamente no navegador, também traz velocidade e possui uma forma mais simplificada para se comunicar com a página que está sendo testada.
A arquitetura do Selenium, apesar de ser bastante robusta e amplamente utilizada, tem uma arquitetura que pode ser menor em termos de velocidade e simplicidade em comparação com as outras ferramentas.
O objetivo dessa seção é avaliar a facilidade para codificar os testes em cada um dos frameworks, comparando a quantidade de código necessária para automatizar os mesmos testes e também a dificuldade em aprender a sintaxe de cada um deles.
O Cypress suporta apenas o Javascript, o que pode demandar a necessidade de o testador aprender uma nova linguagem de programação, mas sua sintaxe simples torna a curva de aprendizado muito alta.
O Cypress possui uma interface amigável ao usuário através do Test Runner, que ajuda na configuração dos testes E2E ou de componentes para testes unitários. Ao selecionar pela primeira vez o tipo de teste desejado, o Test Runner cria as estruturas das pastas com exemplos de testes simples que servem como modelos para criação dos novos testes. A interface do Test Runner é apresentada na Figura 8.
Figura 8. Tela inicial do Test Runner do Cypress
Na execução dos testes E2E, o Cypress carrega automaticamente os navegadores instalados na máquina. Atualmente, o framework oferece suporte ao Chrome, Edge, Firefox, Safari e o Electron, este último um navegador integrado ao Cypress. Após selecionar o navegador desejado, são apresentados os arquivos de teste existentes para execução no modo debug.
O modo de debug auxilia bastante no entendimento do testador do que está acontecendo em cada momento do teste, pois mostra capturas de tela de cada passo e um relatório das chamadas de API executadas e log de valores digitados. Ao clicar no ícone com formato de mira e no elemento desejado, é exibido o melhor seletor para aquele elemento, seguindo as boas práticas de programação, o que auxilia um usuário que não tenha muito conhecimento a encontrar os seletores corretamente. Na Figura 9, temos um exemplo de um teste que foi executado com sucesso em modo debug e um seletor sendo encontrado.
Figura 9. Teste executado pelo Test Runner.
As configurações básicas do projeto, como URL Base, configurações de segurança e outras informações que são necessárias para a execução dos testes, são armazenados no arquivo cypress.config.js, localizado na raiz do projeto. Vale destacar que o Cypress apresentou um problema de compatibilidade com o site utilizado no estudo, travando no momento de realizar o login. Para contornar esse problema, foi necessário configurar para que, ao acessar o site, o Cypress ignorasse as configurações de segurança do navegador, o que seria um problema em um teste real.
O Cypress, por padrão, sempre espera os elementos estarem visíveis para tentar interagir com eles, o que reduz o número de testes com falha por não conseguir realizar uma ação dentro do tempo de espera. Caso seja necessário realizar alguma espera adicional, é possível utilizar o comando cy.wait, mas, em minha experiência com a automação, não foi necessário.
O Cypress encerra o navegador após o final da execução do teste, não sendo necessário criar um método para fechar o browser após cada teste. O framework também possui suporte para testes comunicando com API nativamente através dos comandos cy.request, que executa uma requisição através da API, e o cy.intercept, que permite capturar uma requisição e modificar, ideal para simular erros na execução do teste que não seriam facilmente simulados.
Em razão da facilidade para mapear os objetos da página, assim como para codificar os testes sem a necessidade de importar muitas bibliotecas externas, o projeto ficou com a menor quantidade de linhas de código quando comparado com os outros frameworks, como pode ser observado na Figura 10.
Figura 10. Quantidade de linhas de código do projeto poc cypress [Code Tabs 2024a]
O Playwright possui suporte às linguagens de programação Java, C#, Python, Javascript e Typescript, o que facilita na adesão da ferramenta sem muita necessidade de aprender uma linguagem específica para a codificação.
Após inicializar um projeto no Playwright, as pastas de teste são criadas com testes de exemplo para auxiliar na criação dos novos testes. As configurações básicas, como URL base, diretórios dos testes, formato do relatório e browsers que serão executados paralelamente, são armazenadas no arquivo playwright.config.js, também criado na inicialização.
A captura dos seletores é feita manualmente, o que necessita do usuário conhecimento básico para encontrar os elementos de uma página que será testada. No entanto, a execução do teste no modo debug ajuda bastante na compreensão do que é feito, uma vez que mostra, em cada ponto executado, a localização do elemento procurado. A funcionalidade do modo debug pode ser vista na Figura 11.
Figura 11. Modo debug do Playwright
Os testes no Playwright são executados de forma assíncrona. Por essa razão, é sempre necessário adicionar async nos nomes das funções e await na chamada. Por isso, todas as esperas são executadas de forma automática, sem necessidade de configurar tempos de espera. Os testes no Playwright podem ser executados no Chromium, Firefox ou Webkit, sendo fácil trabalhar com todos os navegadores em relação a performance do tempo de espera deles.
O Playwright encerra o navegador automaticamente após finalizar cada teste, gerando relatórios automáticos de cada execução. Em caso de falha, o relatório é aberto no browser para mostrar o passo onde o erro ocorreu.
Apesar de ter suporte nativo para as bibliotecas de assertividade e de comunicação com a API, é necessário fazer a importação dessas classes do Playwright, o que adicionou algumas linhas de código extra, mas nada que comprometesse o tamanho do projeto. Outro fator que aumentou o número de linhas de código, como pode ser visto na Figura 12, foi a necessidade de fazer a inicialização das variáveis para que cada página nova aberta herdasse o driver da página anterior.
Figura 12. Quantidade de linhas de código do projeto poc_playwright [Code Tabs 2024b]
O Selenium, por ser mais antigo, possui suporte a mais linguagens que os outros frameworks analisados, podendo ser utilizado com Java, C#, Python, PHP, Perl, Ruby, Javascript e Typescript. Com isso, há a redução da necessidade de aprender uma nova linguagem de programação para utilizar na automação dos testes.
Como o projeto foi feito no VS Code, toda a estrutura precisou ser criada do zero, dado que o Selenium não possui ferramentas para auxiliar na criação do projeto, nem cria os testes de exemplo, como ocorre nos outros frameworks, o que demanda conhecimentos básicos sobre automação de testes. Portanto, tal recurso é mais adequado para usuários com mais experiência.
Não existe um arquivo padrão de configurações do projeto, e o Selenium trabalha melhor com o Page Objects Model. Por isso, os métodos básicos de preencher campos, clicar em botões, buscar valores de elemento, entre outras funções comuns são criados na página base com a intenção de serem reutilizados nas outras páginas.
Também é necessário criar um teste base com os métodos para iniciar e encerrar o driver, antes e depois da execução, visto que o browser não é encerrado ao final do teste se não for criado o comando para que isso seja feito especificamente.
A captura dos elementos também é feita manualmente, mas não temos uma ferramenta nativa do Selenium para ajudar na identificação do seletor, sendo necessário procurar alternativas no seu navegador de preferência. Também não existe uma ferramenta de debug nativa do Selenium, fazendo com que seja preciso criar logs para auxiliar na identificação dos problemas que possam ocorrer no teste ou usar o debug da própria IDE (VS Code) utilizada para codificação.
O Selenium não possui esperas padrão na execução dos testes. Por conta disso, deve-se criar esperas implícitas ou explícitas no código para aguardar que a tela termine de carregar completamente, com o intuito de evitar que o elemento não seja encontrado durante a execução do teste. Esse problema foi contornado com a instalação do Mocha no projeto, o que fez com que os testes fossem executados de maneira assíncrona, semelhante ao que foi feito no Playwright, precisando informar async no nome das funções e await na chamada de cada método.
Mesmo com a instalação do Mocha, o projeto enfrentou problemas ao executar alguns testes do fluxo, gerando resultados falso-positivos, em que era informado no log que não foi possível executar uma ação mesmo quando ela havia sido realizada corretamente. O Selenium suporta os navegadores Chrome, Firefox, Edge e Safari, sendo necessário criar algumas configurações adicionais para este último. Na execução dos testes em modo padrão, o teste que verificava adicionar e remover toda a lista de produtos do carrinho de compras sempre retornava um falso-positivo porque o framework não conseguia fazer o clique no último botão para remover do carrinho. Quando executado em modo headless, esse teste passava sem erros, mas outros que funcionavam normalmente retornavam falso-positivo.
Por não possuir suporte nativo, foi necessário adicionar o Mocha ao projeto para fazer a execução dos testes, o Axios para poder fazer as requisições para avaliar o tempo de resposta de alguns testes e o Chai para poder fazer validações mais eficientes. Pela necessidade de importar dependências externas e pelo fato de que, mesmo as classes nativas do Selenium precisam ser importadas para ser utilizadas, isso aumentou consideravelmente o tamanho dos arquivos de código. Combinado com a necessidade de criação dos métodos bases para serem utilizados pelos outros testes e páginas, e a necessidade de fazer a inicialização das variáveis para que cada página nova aberta herdasse o driver da página anterior, o tamanho do código ficou bem maior do que os outros projetos, conforme demonstrado na Figura 13.
Figura 13. Quantidade de linhas de código do projeto poc_selenium [Code Tabs 2024c]
Pela sua sintaxe simples e intuitiva, o Cypress se destacou como a opção mais fácil de aprender, por essa razão gerando o menor número de linhas de código dentre as opções avaliadas.
O Playwright também se destacou bem pela facilidade de aprendizado, embora com um grau de complexidade levemente maior que o framework anterior.
O Selenium possui uma curva de aprendizado mais acentuada e pela necessidade de adicionar dependências externas, se torna mais necessário aprender sobre o framework e também das bibliotecas que precisam ser instaladas.
Para que a medição de tempo fosse realizada da maneira mais precisa, todos os projetos foram codificados com a mesma linguagem de programação (Javascript), localmente na mesma máquina e no navegador Chrome.
Começando pelo Cypress, o tempo total de execução foi de 1 minuto e 17 segundos, com todos os X testes passando sem apontar nenhum erro. O relatório do Cypress Dashboard é exibido nas Figuras 14, 15 e 16 abaixo.
Figura 14. Execução da suíte de teste do poc_cypress
Figura 15. Execução da suíte de teste do poc_cypress
Figura 16. Execução da suíte de teste do poc_cypress Fonte: https://cloud.cypress.io/projects/xsy89k/runs/1/overview?roarHideRunsWithDiffGroupsAndTags=1
Por padrão, o Playwright executa os testes paralelizando entre várias instâncias, mas, para fins de comparação, foi configurado para executar com apenas uma, para ficar semelhante aos outros. O tempo total foi de 31 segundos, com todos os testes passando sem problema. O relatório nativo da execução pode ser visto nas Figuras 17 e 18.
Figura 17. Execução da suíte de teste do poc_playwright
Figura 18. Execução da suíte de teste do poc_playwright
Na execução com o Selenium, o tempo foi de aproximadamente 1 minuto, com um teste sendo executado com um resultado falso-positivo. O relatório gerado no terminal do VS Code está demonstrado nas figuras 19 e 20.
Figura 19. Execução da suíte de teste do poc_selenium
Figura 20. Execução da suíte de teste do poc_selenium
Fazendo a conversão do tempo de execução de todos os testes para milissegundos, para uma avaliação mais adequada, vemos que nos testes que passaram o Selenium teve um desempenho melhor de velocidade, porém, não é possível verificar o tempo de execução do teste que falhou. Vale notar que, nos fluxos mais curtos, as validações do Cypress foram mais rápidas que o Playwright, mas, nos mais longos, o Playwright teve um alto ganho de performance. A Figura 21 mostra o comparativo entre os tempos de execução. Os testes do Cypress e Playwright foram executados no modo headless, enquanto que o teste do Selenium precisou ser executado no modo headed, porque no modo headless vários testes que funcionam estavam retornando erro.
Figura 21. Comparativo do tempo de execução dos testes
A Tabela 5 mostra um comparativo entre as funcionalidades suportadas por cada framework.
| Playwright | Selenium | Cypress | |
|---|---|---|---|
| Linguagens suportadas | Javascript, Java, C#, Python, Ruby, Typescript | Javascript, Java, C#, Python, Ruby, Typescript, PHP, Perl | Javascript, Typescript |
| Navegadores suportados | Chrome, Edge, Firefox, Safari | Chrome, Edge, Firefox, Safari | Chrome, Edge, Firefox, Safari |
| Frameworks suportados | Jest/ Jasmine, AVA, Mocha, Vitest | Mocha, Jest/ Jasmine, TestNG, JUnit, Cucumber, NUnit | Mocha, Jest/ Jasmine, Cucumber |
| Integração contínua | Pode ser facilmente integrado com ferramentas de integração contínua | Pode ser facilmente integrado com ferramentas de integração contínua | Pode ser facilmente integrado com ferramentas de integração contínua |
| Facilidade de uso | Possui uma interface amigável ao usuário e necessita de poucas configurações | Requer mais configurações e possui uma curva de aprendizado mais íngreme | Possui uma uma interface amigável ao usuário e necessita de poucas configurações |
| Experiência na escrita dos testes | Intuitivo | Moderado | Intuitivo |
| Manipulação da DOM | Fácil | Moderado | Fácil |
| Suporte da comunidade | Comunidade crescente | Comunidade grande e ativa com boa documentação e recursos de suporte | Comunidade ativa com boa documentação e recursos de suporte |
| Suporte para execução em modo headless | Sim | Sim | Sim |
| Execução paralela | Suporta execução paralela | Suporta execução paralela | Suporta execução paralela usando ferramentas de CI/CD |
| Controle de tráfego de rede integrado | Sim | Não | Sim |
| Complexidade de configuração inicial | Fácil configuração | Necessita de algum esforço para configurar o framework | Fácil configuração |
| Suporte para iFrame | Sim | Sim | Suporte para Iframe através de plugins, como o cypress-iframe |
| Driver | Sem necessidade de driver | Necessita do driver de cada browser utilizado (A partir da versão 4 do Selenium, o download do driver é feito automaticamente) | Sem necessidade de driver |
| Suporte a múltiplas abas | Sim | Não | Sim |
| Suporte para arrastar e soltar | Sim | Sim | Sim |
| Bibliotecas de assertividade de teste | Mocha, Chai | PyUnit, JUnit, TestNG, e praticamente qualquer outro framework de teste específico de linguagem pode ser adaptado | Mocha/ Chai |
| Relatórios embutidos | Sim | Não | Relatório padrão é o Spec, mas pode ser customizado com outros relatórios suportados |
| Suporte a comunicação entre domínios | Sim | Sim | Sim |
| Funcionalidades de debug | Possui ferramentas de debug embutidas e uma funcionalidade para voltar em determinados momentos da execução para facilitar o debug | Não possui ferramentas de debug embutidas | Possui ferramentas de debug embutidas e uma funcionalidade para voltar em determinados momentos da execução para facilitar o debug |
| Esperas automáticas | Sim | Não | Sim |
| Dashboard | Não | Não | Sim, como funcionalidade paga |
| Funcionalidade para captura de fotos e vídeos embutida | Sim | Não possui, precisa ser customizado para incluir essa funcionalidade | Sim |
| Preços | Gratuito para projetos de código aberto, pago em uso comercial | Gratuito em todos os casos de uso | Gratuito para projetos de código aberto, pago em uso comercial |
Tabela 5. Tabela comparativa
Por sua facilidade de uso e de configuração, o Cypress é recomendado para equipes que possuem testadores iniciantes que ainda estão começando na automação de testes, o que permite criar projetos que testam as funcionalidades Web e API. Embora os testes do Cypress não costumam trazer resultados falso-positivos, vale destacar que o tempo de execução de testes muito grandes costuma ser bastante alto. Tal característica em suítes de teste que possuam muitos testes de tamanho considerável.
O Playwright se saiu melhor na maioria dos critérios, com bom suporte para diferentes linguagens de programação, facilidade de aprendizado, quantidade de recursos embutidos, velocidade de execução dos testes, suporte para testes Web e API, capacidade de executar testes de forma paralela por padrão em vários navegadores e simulação de aplicações móveis, o que torna uma ótima escolha para automação de testes independente do tempo de experiência.
O Selenium, embora tenha apresentado o melhor desempenho no tempo de execução e tenha suporte ao maior número de linguagem de programação entre os frameworks avaliados, se tornou o mais complicado para automatizar em razão da dificuldade maior para configurar e para aprender. Além disso, realça-se a falta de recursos embutidos que demandam a instalação de um alto número de dependências, o que faz do Selenium o mais recomendado para uma equipe com mais experiência em automação de testes.
[ISTQB-CTFL] ISTQB Foundation Level Syllabus, Version 4.0.
Bastos, A.; Rios, E.; Cristalli, R. and Moreira, T. (2007): Base de conhecimento em teste de software. São Paulo: Editora Martins.
França, Emanuel Victor (2023). Automação de testes funcionais para aplicações web: comparativo dos frameworks Cypress e Playwright
Oliveira, T. (2018). Automação de testes: o que é, quando e por que automatizar. https://medium.com/venturus/quais-as-raz%C3%B5es-para-automa%C3%A7%C3%A3o-de-testes-c177cbd9397
Selenium (2023a). The Selenium Browser Automation Project https://www.selenium.dev/documentation/
Selenium (2024a). Selenium https://github.com/SeleniumHQ/selenium
Cypress (2024a). Why Cypress? https://docs.cypress.io/guides/overview/why-cypress
Cypress (2024b). Cypress https://github.com/cypress-io/cypress
Playwright (2024a). Installation https://playwright.dev/docs/intro
Playwright (2024b). Playwright https://github.com/microsoft/playwright
Puppeteer (2024). Puppeteer https://pptr.dev/
Raggo, G. (2023). Puppeteer vs Selenium vs Playwright, a speed comparison https://www.checklyhq.com/blog/puppeteer-vs-selenium-vs-playwright-speed-comparison/
Raggo, G. (2024). Cypress vs Selenium vs Playwright vs Puppeteer speed comparison https://www.checklyhq.com/blog/cypress-vs-selenium-vs-playwright-vs-puppeteer-speed-comparison/
Döring, P. and Brueckner K. (2022). Why we favor Playwright over Selenium or Cypress https://medium.com/tech-p7s1/why-favor-playwright-over-selenium-or-cypress-e96df84c08e1
Akhtar, H (2023). Cypress vs Selenium vs Playwright vs Puppeteer: Core Differences https://www.browserstack.com/guide/cypress-vs-selenium-vs-playwright-vs-puppeteer
Pathak, K (2023). Playwright vs Selenium vs Cypress: A Detailed Comparison https://www.lambdatest.com/blog/playwright-vs-selenium-vs-cypress/
NPM Trends: Comparativo do número de downloads Cypress x Playwright x Selenium Webdriver https://npmtrends.com/cypress-vs-playwright-vs-selenium-webdriver Acessado em: 23/04/2024
Tutorials Point (2020): Cypress Architecture (Test Automation) https://www.tutorialspoint.com/cypress-architecture-test-automation
Learn Microsoft (2023): O que é o Microsoft Playwright Testing? https://learn.microsoft.com/pt-br/azure/playwright-testing/overview-what-is-microsoft-playwright-testing
Code Tabs (2024a): Quantidade de linhas de código do projeto Poc Cypress https://api.codetabs.com/v1/loc/?github=AndradeTC86/poc_cypress
Code Tabs (2024b): Quantidade de linhas de código do projeto Poc Playwright https://api.codetabs.com/v1/loc/?github=AndradeTC86/poc_playwright
Code Tabs (2024c): Quantidade de linhas de código do projeto Poc Selenium https://api.codetabs.com/v1/loc/?github=AndradeTC86/poc_selenium
Footnotes
-
Puppeteer é uma biblioteca de Javascript que fornece uma API de alto nível para controlar o Chrome ou Firefox pelo protocolo DevTools ou WebDriver BiDi. Puppeteer é executado no modo sem cabeçalho por padrão. [Puppeteer 2024] ↩
-
Modelo de Objeto de Documento (DOM) é uma interface de programação para documentos HTML, XML e SVG, fornece uma representação estruturada do documento como uma árvore. ↩