The Evolution of Browser Automation: Christian Bromann [Testμ 2022]

Types of browser automation tools

There are two tools for browser automation, according to Christian Bromann. Here are the snippets he shared:

Conventional tools: Tools like Selenium, Nightwatch, WebdriverIO.

• Built based on W3C WebDriver specifications.
• Supports cross browser testing automation.
• Offers browser and mobile support.
• Limited support towards automation capabilities.
• Open-governed open-source projects with a long history and large communities.
• All the conventional tools are open-sourced.

Non-standard tools: Tools like Cypress and Puppeteer.

• Custom tools with non-standardized automation features, built based on browser APIs or JavaScript emulation.
• Limited cross browser support.
• More automation capabilities and developer focus.
• Company baked and governed open source projects.

For example,

• CypressIO is governed by Cypress.
• TestCafe is governed by DevExpress.
• Playwright is governed by Microsoft.
• Puppeteer is governed by Google.

Christian also spoke elaborately on browser automation strategies we need to remember.

According to Christian, Cypress.io uses web and browser APIs, whereas Puppeteer depends upon browser APIs, Playwright on customer or modified browser APIs, Selenium on WebDriver protocol, and TestCafe through Web APIs.

Ways to automate a browser

Christian divides the browser automation techniques into three:

• Web APIs.
• Browser APIs.
• WebDriver Protocol.

He compared and contrasted the three of them:

Christian spoke about how web APIs have been around since 2004 and are not as supportive of browser automation as its successors, even though tools like Cypress and TestCafe use them.

Similarly, browser API works differently from one version to another with no backward compatibility. For example, you would have to update Puppeteer every time there is a new Chrome release.

It’s also challenging to automate three browsers simultaneously since they all operate in three different languages. All such factors led to the birth of the WebDriver protocol to ensure a consistent automation experience. It’s like having ten assistants to get your automation job done.

With this approach, as per Christian, you can easily automate a browser factory, any mobile factory, or an iOS factory.

With WebDriver Bi-Di, Christian explained how you could provide a number of commands at the same time to multiple factors. He also explained the important features that set it apart.

Christain said that you are also allowed to monkey patch specific APIs and web APIs to have more control over the application, and it’s also backward compatible. He is optimistic that this new protocol can change many things in the future. He explained how you could send over 10,000 commands instead of the recent ones where you can send limited commands.

He then expressed how he wishes to witness the success of WebDriver protocol but also roots for tools like Cypress and Playwright automation since they take automation to the next level, providing fantastic user experience using tools.

This is what he believes will happen in the upcoming days:

He shared his excitement about different web standards, for instance, the web authentication standard, which allows you to create virtual authenticators in WebDriver. He ended the conversation with a quote from Maya and James, who have worked on the Firefox browser.

In the end, our host, Manoj Kumar, laid a few questions in front of him asked by the attendees. He answered them with a willingness to help the community:

• A lot of enterprises have their in-house grid setup. You must have seen a lot of implementations. What should those companies or test architects do?
  Christian: Imagining that they have Docker instances or Kubernetes instances, I think if they use the Selenium grid to manage the browsers and devices, they are well set up because the Selenium grid will be able to support the new Bi-Di protocol. It can become a problem for cloud vendors only when they send many socket messages across the globe.
• How much multi-language support is important when picking up a browser automation tool?
  Christian: I believe the tool needs to be suited for the team that uses it if you have a pool of QA engineers with knowledge in different languages. If they are well-versed with only PHP and Java, then they should use a framework that is built in Java. We see more and more JavaScript frameworks popping up. That’s when we deploy the whole stack where we write a backend in Java. We don’t even need the backend that much anymore. It all depends on what your team needs.
• Is there or will there be any time soon the possibility of having “extensions” (like Chrome extensions) in these tools available to be part of the browser context when running automated tests?
  Christian: Yes, you can already have a Chrome extension installed while running tests on it, even though I’m not sure about the other browsers. There is indeed a need in the industry.
• Which one should you prefer over the other: W3C JSON protocol or tools developed to utilize DevTools of browsers?
  Christian: It depends on your automation needs and based on that, you can pick the automation engine that works best for you. If you still run on the JSON wire protocol, you need to update since you might not be able to run tests on the browser anymore. The reason is that the protocol has been deprecated for a long time. You can choose depending on your front-end developer and other team members’ preference.

We cordially thank Christian for this amazing speech! Hope you found the insights shared over here useful!

After the successful Testμ Conference 2022, where thousands of testers, QA professionals, and developers worldwide joined together to discuss on future of testing.

Join the testing revolution at TestMu AI Testμ Conference 2023. Register now!” – The testing revolution is happening, and you don’t want to be left behind. Join us at TestMu AI Testμ Conference 2023 and learn how to stay ahead of the curve. Register now and be a part of the revolution.