Uma retrospectiva no tempo: a evolução da automação de testes

Jecelyn Yeen

Maksim Sadym

O nascimento da automação de testes

Vamos voltar para a década de 1990, quando o navegador nasceu. A automação de testes só se tornou uma realidade nos anos 2000, com o surgimento dos projetos Selenium e WebDriver (links em inglês) para enfrentar desafios de testes entre navegadores e dispositivos.

Esses dois projetos uniram forças em 2011 como Selenium WebDriver e se tornaram um padrão W3C em 2018. Geralmente, nos referimos a ele como WebDriver ou WebDriver “Clássico”.

A automação de testes antes do WebDriver “Classic” era bastante complicada. Automatizar os testes do navegador melhorou significativamente a qualidade de vida dos desenvolvedores e testadores.

A ascensão do JavaScript

À medida que o desenvolvimento da Web evoluiu para contar mais com 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 elas 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. Uma curiosidade: a primeira versão do Selenium também usava a mesma 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, elas precisam executar comandos remotos para controlar o navegador por protocolos. Os dois principais protocolos de automação são o WebDriver “Clássico” e o Protocolo do Chrome DevTools (CDP).

Na próxima seção, vamos analisar 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 a maioria dos principais navegadores. Os scripts de automação emitem comandos por solicitações HTTP para um servidor de driver, que se comunicam com os navegadores por meio de protocolos internos específicos do navegador.

Embora tenha excelente suporte entre navegadores e suas APIs sejam projetadas para testes, ele pode ser lento e não é compatível com alguns controles de baixo nível.

Por exemplo, imagine que você tem um script de teste que clica em um elemento await coffee.click();. Ela é convertida 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 (links em inglês) para automação. O CDP se comunica diretamente com os navegadores baseados no Chromium por meio de conexões WebSocket, oferecendo desempenho mais rápido e controle básico.

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(); é traduzido 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 nível inferior?

Na época em que o WebDriver “Classic” foi desenvolvido, não havia a necessidade de controles mais específicos. No entanto, os tempos mudaram, a Web tornou-se muito mais eficiente agora e os testes atuais exigem ações mais específicas.

Como o CDP foi projetado para atender a todas as necessidades de depuração, ele oferece suporte a mais controles de baixo nível em comparação com o WebDriver “Clássico”. É capaz de lidar com recursos como:

• Capturando mensagens do console
• Como interceptar solicitações de rede
• Como simular o modo do dispositivo
• Como simular a geolocalização
• E muito mais.

Isso não era possível no WebDriver “Clássico” devido à arquitetura diferente. O WebDriver “Clássico” é 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 para mensagens bidirecionais por padrão.

Próximos passos: WebDriver BiDi

Veja um resumo dos pontos fortes do WebDriver “Classic” e do CDP:

O WebDriver BiDi busca combinar os melhores aspectos do WebDriver "Classic" e CDP. É um novo protocolo padrão de automação de navegadores que está em desenvolvimento.

Saiba mais sobre o projeto WebDriver BiDi (link em inglês): como ele funciona, a visão e o processo de padronização.