Qualquer pessoa que teste aplicativos da net deve estar ciente de um novo protocolo de automação de navegador chamado WebDriver BiDi. Este novo protocolo é uma evolução do padrão WebDriver unique e incorpora alguns dos benefícios de várias outras ferramentas de automação, principalmente, a adição de comunicação bidirecional.
“É um protocolo totalmente novo, que reúne todas as melhores ideias que já existem há algum tempo e tenta padronizá-las por meio do W3C”, disse David Queimaduraschefe de código aberto na BrowserStack (uma empresa de testes de navegadores que faz parte do grupo de trabalho WebDriver BiDi) e presidente do Grupo de Trabalho de Testes e Ferramentas de Navegador no W3C, que é o grupo responsável pelas especificações WebDriver e WebDriver BiDi.
O protocolo WebDriver unique, ou WebDriver Basic, é uma “interface de controle remoto que permite introspecção e controle de agentes de usuário”, de acordo com sua definição W3C. Essencialmente, ele fornece uma maneira de controlar remotamente o comportamento de navegadores da net para que os aplicativos possam ser testados neles.
No entanto, esse protocolo oferece apenas comunicação unidirecional, o que significa que o cliente envia uma solicitação ao servidor, e o servidor pode responder apenas a essa solicitação, explicou Puja Jagani, líder de equipe na BrowserStack e um dos principais responsáveis pelo código do projeto WebDriver BiDi.
“O servidor não pode iniciar a comunicação com o cliente, mas pode apenas responder. Então, se algo de interesse acontece nos navegadores, ele não pode se comunicar de volta com o cliente, a menos que o cliente peça por isso”, explicou Jagani.
BiDi no WebDriver BiDi significa comunicação bidirecional, o que significa que ele permite que eventos no navegador sejam transmitidos de volta para o software program de controle.
De acordo com Jagani, como os navegadores são orientados a eventos, é útil que o navegador consiga compartilhar eventos com o cliente quando algo interessante acontece.
Por exemplo, com esse novo protocolo, os usuários podem assinar os eventos criados quando uma solicitação de rede é enviada de ou para o navegador, o que lhes permite monitorar (ou modificar) todas as solicitações de saída e respostas de entrada.
Um exemplo disso em ação envolve um aplicativo que está apontando para um banco de dados de produção na nuvem. Ao testar esse aplicativo, o WebDriver BiDi pode ser usado para modificar solicitações de saída para apontar para um banco de dados de teste, de modo que o banco de dados de produção não seja inundado com dados de teste.
“Isso só é possível com comunicação bidirecional. Não é possível sem o W3C Protocolo BiDi”, disse Jagani.
CDP vs WebDriver
O Chrome DevTools Protocol (CDP) e o WebDriver Basic têm sido historicamente comparados com frequência porque ambos são ferramentas de baixo nível — ferramentas que executam comandos remotos fora do navegador, como abrir várias guias ou simular o modo de dispositivo, Jecelyn Yeen, engenheira sênior de relações com desenvolvedores do Chrome, e Maksim Sadym, engenheiro de software program do Google, explicaram em um postagem de weblog.
Ferramentas de alto nível, por outro lado, são aquelas que executam comandos dentro do navegador. Exemplos delas incluem Puppeteer, Cypress e TestCafe.
O CDP habilita a comunicação bidirecional, mas é limitado para fins de teste porque só funciona para navegadores baseados em Chromium, como o Google Chrome, e não funcionaria no Firefox ou Safari. De acordo com Yeen e Sadym, “o WebDriver BiDi visa combinar os melhores aspectos do WebDriver ‘Basic’ e do CDP.”
No entanto, Burns, da BrowserStack, enfatizou que esse novo protocolo não pretende substituir o CDP, mas sim que é um protocolo de teste e automação inteiramente novo. “O CDP sempre estará presente nos navegadores Chromium”, disse ele.
Já tem suporte para navegador
O criador do CDP, Google, está fortemente envolvido no desenvolvimento e suporte do WebDriver BiDi, assim como a Mozilla. “Estamos felizes que a Mozilla e o Google vieram e nos ajudaram a chegar a esse ponto em que ele é padronizado e agora todos podem se beneficiar dele”, disse Burns. Ele acrescentou que a Apple ainda não chegou lá, e não está claro no momento quando o suporte para o WebDriver BiDi estará disponível em navegadores baseados em WebKit.
“Às vezes, os padrões podem se mover em um ritmo glacial, e parte disso é por um bom motivo. Envolve criar os pontos de colaboração e obter consenso — e às vezes o consenso pode ser muito difícil, especialmente quando Google, Mozilla e Apple têm suas próprias ideias sobre o que torna algo melhor, e então obter isso pode ser muito, muito lento para implementar”, explicou Burns.
Ferramentas de automação de testes e empresas de testes também começaram a oferecer suporte a elas
Além dos navegadores precisarem dar suporte a ele, outra parte do quebra-cabeça é colocar as ferramentas de automação de testes e os provedores de testes a bordo. Felizmente, as ferramentas de automação Selenium e WebDriverIO, assim como as empresas de testes Pilha de NavegadorSauceLabs e LambdaTest fazem parte do Grupo de Trabalho WebDriver BiDi.
WebdriverIO e Selenium já têm algum suporte para o novo protocolo e O BrowserStack suporta também. O próprio selênio também é atualizando toda a sua implementação do WebDriver para o WebDriver BiDi. Burns explicou que a adaptação da versão clássica do WebDriver para o BiDi é a última grande parte do processo, e espera-se que seja concluída no próximo ano.
“É um projeto conduzido por voluntários, então isso acontece quando a largura de banda e o tempo de todos combinam, então é feito em surtos ou períodos de trabalho, certo? Mas acho que é assim para o desenvolvimento de código aberto em geral”, disse Jagani, que também é membro do Comitê de Liderança Técnica do Selenium.
Ela observou que até o Selenium 5 (a versão atual é 4.24), o objetivo é ter pelo menos as APIs de alto nível prontas, que abrangem uma série de casos de uso, como dar ao usuário a capacidade de ouvir logs do console e a capacidade de fazer autenticação básica para seu website, para citar alguns.
Assim que o Selenium 5 for lançado, o próximo objetivo será começar a transição de comandos um por um do WebDriver Basic para o WebDriver BiDi. “Espero que, no Selenium 6, sejamos apenas BiDi”, disse ela. Ela continuou explicando que é um longo processo com muitas variáveis externas. Os navegadores ainda estão no processo de implementação, e assim que o BiDi estiver na versão estável do navegador, é quando o Selenium entra e pode começar a implementá-lo. Depois disso, ainda há um período em que os usuários precisarão usá-lo e dar suggestions para que o Selenium possa garantir que sua implementação seja resiliente.
Jagani disse que a experiência do usuário deve permanecer a mesma quando o Selenium for migrado para o BiDi, e não haverá uma grande mudança.
“É isso que o Selenium tenta fazer — mesmo do Selenium 3 para o 4 — tentamos garantir que seja uma integração perfeita com o mínimo de mudanças de ruptura”, disse ela. “O Selenium é muito grande em compatibilidade com versões anteriores, tanto quanto possível, ou pelo menos garante que estamos descontinuando coisas conforme necessário para que você saiba que iremos removê-las e dar avisos suficientes. Essa experiência para usuários que usam o WebDriver Basic permaneceria a mesma, porque eventualmente serão as mesmas APIs, apenas usando BiDi por baixo dos panos.”
Para aproveitar os novos recursos avançados que o BiDi traz, haverá novas APIs disponíveis, que serão semelhantes àquelas com as quais os usuários já estão familiarizados.