
Those involved in web application testing should become familiar with a cutting-edge browser automation protocol known as WebDriver BiDi. This protocol extends the classic WebDriver standard by introducing bidirectional communication, integrating superior features from various automation frameworks.
“WebDriver BiDi represents the culmination of the best ideas from existing technologies, now being standardized through the W3C,” mentioned David Burns, the head of open source at BrowserStack. Burns is also the chair of the Browser Testing and Tools Working Group at W3C, which oversees both WebDriver and WebDriver BiDi specifications.
Originally, the WebDriver protocol, also known as WebDriver Classic, is defined by the W3C as a “remote control interface that allows introspection and control over user agents.” It is essentially a method for remotely managing web browsers to facilitate application testing within them.
However, WebDriver Classic was limited to unidirectional communication, where a client’s request is met with a single server response, as explained by Puja Jagani, team lead at BrowserStack and a significant contributer to the WebDriver BiDi project.
“The server cannot initiate communication with the client but can only respond. So if something of interest happens in the browsers it cannot communicate back to the client unless the client asks for it,” explained Jagani.
The BiDi in WebDriver BiDi stands for bidirectional communication, meaning that it actually allows events in the browser to stream back to the controlling software.
According to Jagani, because browsers are event-driven, it’s helpful for the browser to be able to share events back to the client when something interesting happens.
For instance, with this new protocol, users can subscribe to the events created when a network request is sent to or from the browser, which enables them to monitor (or modify) all outgoing requests and incoming responses.
An example of this in action involves an application that is pointing to a production database in the cloud. When testing that application, WebDriver BiDi could be used to modify outgoing requests to point to a test database so that the production database isn’t flooded with test data.
“This is only possible with bidirectional communication. It is not possible without the W3C BiDi protocol,” said Jagani.
The Chrome DevTools Protocol (CDP) and WebDriver Classic have historically been often compared because they are both low-level tools — tools that execute remote commands outside of the browser, such as opening multiple tabs or simulating device mode, Jecelyn Yeen, senior developer relations engineer for Chrome, and Maksim Sadym, software engineer at Google, explained in a blog post.
High-level tools, by contrast, are those that execute commands within the browser. Examples of these include Puppeteer, Cypress, and TestCafe.
CDP does enable bidirectional communication, but it’s limited for testing purposes because it only works for Chromium-based browsers, like Google Chrome, and wouldn’t work in Firefox or Safari. According to Yeen and Sadym, “WebDriver BiDi aims to combine the best aspects of WebDriver ‘Classic’ and CDP.”
However, BrowserStack’s Burns emphasized that this new protocol isn’t intended to replace CDP, but rather it’s a new testing and automation protocol entirely. “CDP is always going to be there on Chromium browsers,” he said.
CDP’s creator, Google, is heavily involved in developing and supporting WebDriver BiDi, as is Mozilla. “We are glad that Mozilla and Google have come and helped us get it to that point where it’s standardized and now everyone can benefit from it,” Burns said. He added that Apple isn’t quite there yet, and it’s not clear at the moment when support for WebDriver BiDi will be available in WebKit-based browsers.
“Sometimes standards can move at a glacial pace, and part of that is for good reason. It involves creating the collaboration points and getting consensus — and sometimes consensus can be really hard, especially where Google, Mozilla, and Apple, they have their own ideas of what makes something better, and so getting that can be really, really slow to implement,” Burns explained.
In addition to the browsers needing to support it, another piece of the puzzle is getting the testing automation tools and testing providers on board. Fortunately, the automation tools Selenium and WebDriverIO, as well as the testing companies BrowserStack, SauceLabs, and LambdaTest, are all part of the WebDriver BiDi Working Group.
WebdriverIO and Selenium already have some support for the new protocol, and BrowserStack supports it too. Selenium itself is also updating its entire implementation from WebDriver to WebDriver BiDi. Burns explained that retrofitting the classic version of WebDriver to BiDi is the last major piece of the process, and is expected to be complete within the next year.
“It’s a volunteer-driven project, so this happens when everyone’s bandwidth and time matches, so it gets done in like spurts or chugs of work, right? But I think that’s how it is for open source development in general,” said Jagani, who is also a member of the Selenium Technical Leadership Committee.
She noted that by Selenium 5 (the current version is 4.24), the goal is to have at least the high-level APIs done, which cover a number of use cases, like giving the user the ability to listen to console logs and the ability to do basic authentication for their website, to name a couple.
Once Selenium 5 is released, the subsequent aim is to transition commands incrementally from WebDriver Classic to WebDriver BiDi. “Hopefully, by Selenium 6, we are BiDi only,” she mentioned. She elaborated that this transition involves a lengthy process influenced by multiple external factors. As browsers are currently adopting WebDriver BiDi, its integration into Selenium will commence once WebDriver BiDi stabilizes in browsers. Following this integration, there will be a phase for user feedback, which is crucial for Selenium to confirm the robustness of its implementation.
Welcome to DediRock, your trusted partner in high-performance hosting solutions. At DediRock, we specialize in providing dedicated servers, VPS hosting, and cloud services tailored to meet the unique needs of businesses and individuals alike. Our mission is to deliver reliable, scalable, and secure hosting solutions that empower our clients to achieve their digital goals. With a commitment to exceptional customer support, cutting-edge technology, and robust infrastructure, DediRock stands out as a leader in the hosting industry. Join us and experience the difference that dedicated service and unwavering reliability can make for your online presence. Launch our website.