Selenium 4 testing

New functionalities in Selenium 4 will include:

• Selenium Webdriver will be completely W3C standardized
• New find element options
• Chrome Debugging Protocol (CDP) support
• Window Handling improvements
• Screenshot improvements
• Docker support for Selenium grid deployments

Selenium WebDriver W3C

Selenium WebDriver has long been using the JSON Wire Protocol. There was no official W3C spec for this, so slight variations were possible in this protocol.

With Selenium 4, browser vendors will be able to implement the strict W3C (World Wide Web Consortium) WebDriver protocol, which results in a more uniform implementation.

The creation of this new W3C WebDriver protocol started over 5 years ago and has more recently been approved as a standard.

The most important changes are how you create a new session, and the Actions API.

Create a new session

With the W3C WebDriver protocol, tests will need to converted from using desiredCapabilities to capabilities.

Before, you could specify the desired capabilities of your test like this:

With the new capabilities method, you can specify the same capabilities like this:

The new session capabilities use firstMatch (formerly known as desiredCapabilities) and alwaysMatch (formerly known as requiredCapabilities).

Please see WebDriver W3C's new Session documentation for more information about this.

With TestingBot, we've been providing custom capability options to customise your tests. For W3C capabilities, please see the Selenium 4 capabilities example.

You can use a tb:options map of custom options to customise your tests on the TestingBot platform.

Actions API

With the Actions API, you can perform multiple actions during your test simultaneously. For example: you can create a test that clicks on multiple elements while holding the control key.

Actions allow you to chain keyboard and mouse events together, and create more complex interactions with the object under test.

Below is an example of an action:

New find element options

Selenium 4 comes with a new locators to find elements on a page. These new locators are called the Relative Locators, previously called Friendly Locators (this idea is inspired by the Sahi automation tool).

This new locator allows you to find an element, relative to another element on the page.

There are 5 different locator parameters that you can use:

• above(): finds an element/elements located above an element.
• below(): finds an element/elements located below an element.
• near(): finds an element/elements located near an element.
• toLeftOf(): finds an element/elements located to the left of an element.
• toRightOf(): finds an element/elements located to the right of an element.

These new locators allow for more flexibility in writing your tests, it improves readability and stability.
Please see this simple example on how to use these new locators:

New exceptions have been added, to provide the user with better information on what is going wrong (ElementClickInterceptedError, NoSuchCookieError and others).

Chrome Debugging Protocol (CDP)

CDP is the protocol used by Chrome to power its Chrome Developer Tools debugger. This protocol is used by (headless) automation tools such as Puppeteer and Playwright. It is not the most user friendly API, but it is very powerful and performant. It allows for network stubbing, mocking geolocations, taking full page screenshots and more.

With this new support built in, you can write tests that integrate even more tightly into the Chromium browser (Chrome and Microsoft Edge).

To get started, please see this code example:

You can find more CDP commands you can use on this page.

Window Handling Improvements

During a test, you can now easily go to full-screen mode and back.
Handling windows is also improved, offering better control to open/close new windows and tabs.

Your tests can now control multiple windows during the same test, for example:

You can have a handle to the new window, while still being able to control the main window as well.

The WindowType.WINDOW parameter instructs the browser to create a new window. Similarly, you can instruct it to create a new tab instead: WindowType.TAB

Screenshot Improvements

It is now possible to take screenshots of individual UI elements. Before Selenium 4, the only option testers had was taking a screenshot of the viewport and then programmatically cropping the screenshot with specific coordinates. Now, you can take screenshots of specific WebElements; buttons, links and other DOM elements. This is great news for testers looking to do visual testing.

Please see the example below on how to do this:

Docker support for Selenium grid deployments

The Selenium Grid code has been redesigned and can now easily be used in combination with Docker/Kubernetes. It is much more scaleable and architected as a distributed system.

Of course with TestingBot, you do not have to worry about setting up and maintaining such a Grid, as we do that for you.

Getting Started

Excited to try out Selenium 4? Please see the example below on how to configure your tests to use Selenium 4 Alpha with TestingBot: