O nascimento da automação de testes
Vamos voltar para a década de 1990, quando surgiu o navegador da Web. A automação de testes não se tornou realidade até os anos 2000, com o surgimento dos projetos Selenium e WebDriver (links em inglês) para enfrentar os desafios de testes entre navegadores e dispositivos.
Esses dois projetos uniram forças em 2011 como o Selenium WebDriver e se tornaram um padrão W3C em 2018. Em geral, ele é chamado de WebDriver ou WebDriver " Classic".
Testar a automação antes do WebDriver “ Classic” era bem complicado. A automatização dos testes de navegador melhorou significativamente a qualidade de vida dos desenvolvedores e testadores.
A ascensão do JavaScript
À medida que o desenvolvimento da Web evoluiu para depender mais de JavaScript, surgiram novas soluções de automação, como WebdriverIO, Appium, Nightwatch, Protractor (descontinuado), Testcafe, Cypress, Puppeteer e Playwright.
Abordagens de automação
De modo geral, essas ferramentas podem ser organizadas em dois grupos principais com base em como automatizam os navegadores:
- Alto nível: ferramentas que executam JavaScript no navegador. Por exemplo, o Cypress e o TestCafe usam APIs da Web e Node.js para executar testes diretamente no navegador. Curiosidade: a primeira versão do Selenium também usou essa abordagem.
- Nível baixo: ferramentas que executam comandos remotos fora do navegador. Quando as ferramentas exigem um controle ainda maior, como abrir várias guias ou simular o modo de dispositivo, é nesse momento que elas precisam executar comandos remotos para controlar o navegador por protocolos. Os dois protocolos principais de automação são o WebDriver " Classic" e o Chrome DevTools Protocol (CDP).
Na próxima seção, vamos conhecer esses dois protocolos para entender os pontos fortes e as limitações deles.
WebDriver "Clássico" vs. Protocolo do Chrome DevTools (CDP)
O WebDriver " Classic" é um padrão da Web compatível com todos os principais navegadores. Os scripts de automação emitem comandos por solicitações HTTP para um servidor de driver, que então se comunica com os navegadores por protocolos internos específicos do navegador.
Embora ele tenha um excelente suporte entre navegadores e as APIs sejam projetadas para testes, ele pode ser lento e não oferece suporte a alguns controles de baixo nível.
Por exemplo, imagine que você tem um script de teste que clica em um elemento await coffee.click();. Ele é convertido em uma série de solicitações HTTP.
# WebDriver: Click on a coffee element
curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
-H 'Content-Type: application/json'
-d '{}'
Por outro lado, o protocolo do Chrome DevTools (CDP) foi inicialmente projetado para o Chrome DevTools e depuração, mas foi adotado pelo Puppeteer para automação. O CDP se comunica diretamente com navegadores baseados no Chromium por meio de conexões WebSocket, proporcionando desempenho mais rápido e controle de baixo nível.
No entanto, ele só funciona com navegadores baseados no Chromium e não é um padrão aberto. Além disso, as APIs de CDP são relativamente complexas. Em alguns casos, trabalhar com o CDP não é ergonômico. Por exemplo, trabalhar com iframes fora do processo exige muito esforço.
Por exemplo, clicar em um elemento await coffee.click(); é convertido em uma série de comandos do CDP.
// CDP: Click on a coffee element
// Mouse pressed
{
command: 'Input.dispatchMouseEvent',
parameters: {
type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}
// Mouse released
{
command: 'Input.dispatchMouseEvent',
parameters: {
type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}
Quais são os controles de baixo nível?
Na época em que o WebDriver "Clássico" foi desenvolvido, não havia necessidade de controle básico. Mas os tempos mudaram, a Web agora tem muito mais recursos, e testar hoje exige ações mais refinadas.
Como o CDP foi criado para atender a todas as necessidades de depuração, ele oferece suporte a mais controles de baixo nível em comparação ao WebDriver "Clássico". Ele consegue gerenciar recursos como:
- Como capturar mensagens do console
- Como interceptar solicitações de rede
- Como simular o modo do dispositivo
- Simular geolocalização
- E muito mais.
Isso não era possível na versão clássica do WebDriver devido à arquitetura diferente. O WebDriver “versão clássica” é baseado em HTTP, o que dificulta a inscrição e a detecção de eventos do navegador. O CDP, por outro lado, é baseado em WebSocket, com suporte a mensagens bidirecionais por padrão.
A seguir: WebDriver BiDi
Veja um resumo dos pontos fortes do WebDriver "Clássico" e do CDP:
| WebDriver "clássico" | Protocolo do Chrome DevTools (CDP) |
|---|---|
| Melhor suporte entre navegadores | Mensagens rápidas e bidirecionais |
| Padrão W3C | Fornece controle de baixo nível |
| Criado para testes |
O WebDriver BiDi tem como objetivo combinar os melhores aspectos do WebDriver "classic" e do CDP. Trata-se de um novo protocolo padrão de automação de navegador que atualmente está em desenvolvimento.
Saiba mais sobre o projeto WebDriver BiDi: como ele funciona, a visão e o processo de padronização.