Se você estiver iniciando um projeto de automação de testes, a questão Selenium vs Playwright surgirá rapidamente. Os resultados da pesquisa podem parecer uma questão resolvida, mas a resposta certa depende da sua equipe, dos testes existentes e dos navegadores aos quais você deve oferecer suporte.

Este guia os compara com as coisas que você realmente sentirá no trabalho diário. Os exemplos de código mostram o estilo típico de cada ferramenta e não os executamos neste artigo. Também evitamos citar percentagens de velocidade, porque os benchmarks publicados variam muito e muitas vezes vêm dos fornecedores. Meça em sua própria aplicação se a velocidade decidirá o assunto.

A resposta curta

Escolha Playwright para a maioria dos novos projetos de testes web, especialmente se sua equipe puder trabalhar em JavaScript, TypeScript, Python, Java ou .NET. Você obtém mais recursos prontos para uso e menos tempo gasto em infraestrutura e esperas instáveis.

Escolha Selenium se você já tiver uma suíte grande e funcional, se precisar de uma linguagem que o Playwright não suporta oficialmente, como Ruby, ou se precisar testar em versões reais de navegadores e plataformas disponíveis por meio de uma grade Selenium ou nuvem de dispositivos.

Selênio vs Dramaturgo lado a lado

Arquitetura: como cada uma conversa com o navegador

Selenium envia comandos usando o protocolo W3C WebDriver, um padrão formal. Seu código se comunica com um driver, como o ChromeDriver, que controla o navegador, sendo cada comando geralmente uma solicitação HTTP separada. Como os fornecedores de navegadores oferecem suporte a esse padrão, ele possui ampla compatibilidade. Um protocolo mais recente, WebDriver BiDi, está adicionando comunicação bidirecional e streaming de eventos ao padrão.

O Playwright mantém uma conexão persistente com o navegador e usa suas próprias versões corrigidas do Chromium, Firefox e WebKit. Como a conexão é direta e bidirecional, ela pode reagir a eventos do navegador e cada teste pode ser executado em seu próprio contexto de navegador leve. É por isso que a maioria das comparações classifica o Playwright como mais rápido, embora a lacuna real dependa da sua aplicação e dos seus testes.

Um teste em ambas as ferramentas

Aqui está o mesmo teste de login, escrito em Python, em um site de prática pública.

Selênio

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

def test_login(driver):
    driver.get("https://the-internet.herokuapp.com/login")
    driver.find_element(By.ID, "username").send_keys("tomsmith")
    driver.find_element(By.ID, "password").send_keys("SuperSecretPassword!")
    driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()

    message = WebDriverWait(driver, 10).until(
        EC.visibility_of_element_located((By.ID, "flash"))
    )
    assert "You logged into a secure area" in message.text

Você também precisa de um fixture para criar e fechar o driver, como mostramos em nosso tutorial Selenium Python.

Dramaturgo

from playwright.sync_api import Page, expect

def test_login(page: Page):
    page.goto("https://the-internet.herokuapp.com/login")
    page.get_by_label("Username").fill("tomsmith")
    page.get_by_label("Password").fill("SuperSecretPassword!")
    page.get_by_role("button", name="Login").click()

    expect(page.locator("#flash")).to_contain_text("You logged into a secure area")

Isso depende do plugin pytest-playwright, que fornece o fixture page. É mais curto, principalmente porque a espera está incorporada em expect e porque localizadores como get_by_role descrevem a página da maneira como o usuário a vê. Com o Selenium, você pode reduzir consideravelmente esse padrão com ajudantes e o Modelo de objeto de página, que recomendamos em qualquer uma das ferramentas.

Testes de espera e instáveis

O tempo é a principal causa de testes de navegador instáveis e é onde as duas ferramentas mais diferem no uso diário.

No Selenium, você é responsável pela sincronização. Esperas explícitas funcionam bem, mas alguém precisa se lembrar delas em todos os lugares, e as equipes que esquecem muitas vezes recorrem a time.sleep. Nosso guia sobre esperas do Selenium explica como fazer isso corretamente.

No Playwright, as ações verificam automaticamente se um elemento está visível, estável, habilitado e capaz de receber eventos antes de agir. As asserções que priorizam a Web continuam tentando até o tempo limite. Você ainda pode escrever testes instáveis, por exemplo, com dados de teste de baixa qualidade, mas uma grande fonte de problemas é tratada por padrão.

Navegadores e idiomas

É aqui que o Selenium mantém uma vantagem real. A construção do WebKit do Playwright é próxima do mecanismo do Safari, mas não é a mesma coisa que o Safari em um Mac ou iPhone. Se o comportamento real do Safari for crítico, o Selenium com SafariDriver, ou uma nuvem de dispositivo real, aproxima você do que seus usuários realmente executam.

Da mesma forma, o Playwright testa suas versões de navegador integradas, embora também possa controlar canais Chrome e Edge instalados. O Selenium orienta os navegadores que você instala, o que ajuda se você precisar oferecer suporte a versões específicas. Para aplicativos móveis nativos, a resposta completa também não é: Appium, que é construído sobre conceitos do WebDriver, é a ferramenta usual.

Nas linguagens, o Selenium suporta oficialmente Ruby e tem uma longa história em equipes Java. A versão Node.js do Playwright também possui as ferramentas mais completas, já que o executor de testes completo está lá. Outras linguagens obtêm a biblioteca principal e integram-se com suas próprias estruturas de teste.

Depuração

O dramaturgo tem uma liderança clara aqui. Seu visualizador de rastreamento registra cada ação, juntamente com instantâneos do DOM, chamadas de rede e logs do console, para que você possa percorrer uma execução de CI com falha após sua conclusão. Seu modo UI e codegen também ajudam você a escrever testes com mais rapidez. Veja nosso Tutorial de dramaturgo para iniciantes para saber como usá-los.

Com o Selenium, você mesmo monta isso, a partir de capturas de tela em caso de falha, logs do navegador, vídeo do seu provedor de grade e relatórios da sua estrutura de teste. Funciona bem e muitas equipes têm configurações excelentes, mas é preciso esforço para construí-las.

Recursos de rede e API

O Playwright pode interceptar e simular solicitações de rede com algumas linhas de código, o que é útil para testar estados de erro:

page.route("**/api/orders", lambda route: route.fulfill(status=500))

Ele também inclui um cliente de solicitação de API, para que você possa criar dados de teste por meio de uma API antes de iniciar o navegador. O Selenium 4 adicionou alguns recursos de rede por meio do protocolo Chrome DevTools e BiDi, mas o suporte e a conveniência variam de acordo com o navegador e o idioma. Muitos usuários do Selenium adicionam um proxy ou uma biblioteca HTTP separada, como em ferramentas de teste de API.

Execuções paralelas e escala

O executor do Playwright lida com trabalhadores paralelos e fragmentação em máquinas CI com opções simples. Os contextos do navegador são baratos, portanto o isolamento não requer um navegador totalmente novo para cada teste.

O Selenium usa o Selenium Grid para distribuir testes entre máquinas e versões de navegadores, e estruturas de teste lidam com o paralelismo. O Grid é mais para ser executado, mas está comprovado em grande escala, e muitas nuvens de dispositivos comerciais o suportam diretamente.

Você deve migrar do Selenium para o Playwright?

Não automaticamente. Um conjunto de trabalho é valioso e reescrever leva tempo para testar o produto. Faça estas perguntas primeiro:

1. Existe um problema mensurável? Testes instáveis ou depuração lenta são bons motivos. “É mais recente” não é.
2. Qual é o tamanho do conjunto? Cem testes podem ser movidos. Dez mil é um grande projeto.
3. Os objetos da sua página estão limpos? Boas abstrações tornam a mudança muito mais barata.
4. Você confia em recursos específicos do Selenium? Verifique primeiro as necessidades da sua grade e do dispositivo.

Se você se mover, vá gradualmente. Escreva novos testes no Playwright, migre primeiro os testes antigos mais complicados e execute os dois lado a lado até que o conjunto antigo seja pequeno o suficiente para ser retirado. Não traduza os testes linha por linha, pois isso transporta sleeps e localizadores antigos. Evite também os erros abordados em erros de automação de testes.

Como escolher

O melhor de tudo é fazer um pequeno piloto. Automatize suas três jornadas mais complicadas em cada ferramenta em relação ao seu próprio aplicativo, em seu próprio CI, e compare o código, a velocidade e a facilidade com que você pode depurar uma falha. Uma semana de evidências supera qualquer artigo comparativo, incluindo este. Se Cypress também estiver na sua lista, leia Dramaturgo vs Cypress.

Considerações finais

O dramaturgo geralmente é o lugar mais fácil para começar, e o Selenium continua sendo um padrão confiável com amplo alcance. Nenhum dos dois salvará um conjunto de testes mal projetado. Escolha com base em suas restrições reais, invista em localizadores estáveis ​​e bons dados de teste e mantenha seu conjunto focado no que é mais importante para seus usuários.

Perguntas frequentes

Continue aprendendo