From Selenium 3 to Selenium 4: A Detailed Migration Guide

Selenium has undoubtedly been the most popular open-source test automation tool over the last decade. As web apps and browsers evolve rapidly, so does Selenium evolve consistently — living by the ethos of “Software is only as good as how frequently you update it!”.

Over a span of about two years now, I have guided several QA teams on their journey of upgrading from Selenium 3 to 4. Through this article, I want to distill those learnings into an actionable playbook for you to migrate seamlessly as well.

Brief History of Selenium Versions

Let‘s first understand where Selenium 3 and Selenium 4 stand in the overall Selenium releases timeline:

Release	Purpose
Selenium 1	Introduction of Selenium RCClient-Server architecture for browser automation
Selenium 2	Merging of WebDriver API into SeleniumCore framework enhancement
Selenium 3	Browser expansionFirefox, Chrome, Headless browser support
Selenium 4	Architectural standardizationW3C protocol adoption, Grid enhancements

As highlighted above, Selenium 4 marks some major architecture changes aimed at standardization along with additional features — chief among them being migration to the W3C protocol.

Whereas Selenium 3 introduced support for new generation browsers like Firefox and Chrome along with Headless testing capabilities.

Let‘s look at a more detailed comparison of Selenium 3 vs Selenium 4:

Metric	Selenium 3	Selenium 4
Initial Release	2016	2021
Latest Version	3.141	4.7
Wire Protocol	JSON Wire Protocol	W3C Standard
Architecture	Client – Server Hub – Node separation	Integrated Hub + Node
Locating Strategy	Absolute Identifiers only	Relative Locators added
Platform Support	Cross-browser support	DevTools support added
Configuration	DesiredCapabilities	Options class

With this context of where these Selenium versions stand and the improvements added in V4, let‘s dig deeper into what all constitutes the big shift.

Transition in Architecture

One of the fundamental changes that enables several downstream benefits in Selenium 4 is the adoption of the W3C standard as the communication protocol.

Let‘s visually understand how this impacts the Selenium architecture:

Selenium 3 architecture showing JSON Wire Protocol usage

Here Selenium 3 components are organized into distinct layers — with the JSON Wire Protocol acting as the bridge across Client Libraries, Drivers and Browsers.

Selenium architecture updated in Version 4 to leverage W3C standard

In Selenium 4, you can observe how the W3C protocol replaces JSON Wire to communicate directly with the browsers. This eliminates an entire orchestration layer leading to the downstream benefits we will cover next.

Benefits of Adopting W3C Standard

Leveraging the W3C protocol brings 3 significant advantages:

1. No browser-specific implementations: Earlier with JSON Wire Protocol, vendors had to build custom bindings for each browser to adapt to Selenium. This caused inconsistencies across browser behaviors. With W3C adoption, no more browser-specific code is needed as all browsers speak the standard protocol already.

2. Architecture simplification: As observed earlier, removal of intermediate orchestration layer leads to a more streamlined components interaction.

3. Better stability: W3C being the open standard adopted by browser vendors directly, keeps getting updated as per latest browser versions. This prevents brittle automation failures due to protocol mismatches.

Thus, the fundamental architecture update brings simpler, vendor-neutral interaction between Selenium binding and target browsers — leading to more robust automation.

With this context, let‘s now understand some of the tactical changes involved in migrating your scripts and framework.

Selenium Grid Enhancements

One of Selenium‘s most popular features that enables scaled-up test distribution is Selenium Grid. Selenium 4 brings in some structural changes and enhancements to Grid making distributed testing easier to scale.

Integrated Hub and Nodes

Earlier in Selenium 3, Selenium Grid involved starting up the Hub and Nodes as separate processes. So you always had to spawn up these Grid pieces before executing tests.

Selenium 3 Grid showing Hub and Nodes separation requiring orchestration

Whereas now in Selenium 4, Hub and Nodes run within the same Selenium server without any need for external infrastructure.

Selenium 4 Grid with integrated Hub and Nodes

This makes distributed testing infrastructure easier to deploy and scale on the fly based on parallel testing needs.

Improved Scalability

With Selenium 4, the Grid architecture has been updated to split provisioning of test sessions across four core processes:

• Router: Routes test requests to Nodes
• Distributor: Distributes sessions across Nodes
• Node: Browser instances executing tests
• SessionQueue: Central session status tracking

This separation of responsibilities allows better scalability in handling multiple parallel test runs compared to Selenium 3.

Here‘s a metric indicating how Grid 4 scales better:

Metric	Selenium 3	Selenium 4
Peak Test Executions Per Hour	1800	7200

As the benchmark indicates, Selenium Grid 4 can handle up to 4x more test executions per hour out-of-the-box vs Selenium 3.

Docker Support

Selenium Grid 4 comes with first-class integration with Docker for simplified management. Creation of nodes is now as easy as spinning up Selenium docker images.

Here is a quick snippet to attach a Chrome node to Grid 4 using Docker:

docker run -d -p 4444:4444 --network grid -e SE_EVENT_BUS_HOST=grid -e SE_EVENT_BUS_PUBLISH_PORT=4442 -e SE_EVENT_BUS_SUBSCRIBE_PORT=4443 selenium/node-chrome

This enables dynamically attaching nodes without having to reconfigure grids.

With easier distributed testing infrastructure, let see how the IDE experience has evolved in Selenium 4.

Revamped Selenium IDE

The Selenium IDE was historically a record-and-playback tool limited to Firefox. With Selenium 4, it gets transformed with improvements across the board spanning UX, platform support and integration.

IDE Improvements

First and foremost, The Selenium IDE user interface has been redesigned from scratch for improved user experience:

Enhanced user interface of the Selenium IDE

As observed, menus and navigation elements have been upgraded for streamlined testcase creation flows.

Additionally, Selenium IDE now supports both Firefox and Google Chrome as target browsers:

Browsers Supported:

- Firefox v84+ 
- Chrome v90+

This provides more environment flexibility to users for test case development.

Enhanced Test Execution

The IDE in Selenium 4 comes bundled with a companion CLI — Side Runner that unlocks more test running environments without dependencies:

Executing Tests Using Side Runner

Execution Target	Command
Local Grid	side-runner {projectDir}
Cloud Grid	side-runner --server {GridURL} {projectDir}
Docker Grid	side-runner --docker {GridImage} {projectDir}

As you can observe above, Side Runner provides integrated commands to run IDE test cases across Local, Cloud or Docker Grid configs without any extra installation.

This makes the updated IDE a lot more powerful compared to just Firefox playback.

Relative Locators

One of my favorite features introduced in Selenium 4 is Relative Locators. These new locator strategies revolutionize element identification by eliminating dependency on absolute selectors.

The relative locator types supported out-of-the-box are:

• above
• below
• toLeftOf
• toRightOf
• near

Here is an example leveraging relative locators:

Log In Page HTML

<input id= "username" placeholder="Email">

<input id ="password" placeholder="Password"> 

<button>Submit</button>

Selenium Test

// Locate password relative to username 
RelativeLocator pwdBox = RelativeLocator.with(By.id("username"))
                                          .below(By.id("password"));

WebElement password = driver.findElement(pwdBox);
password.sendKeys("test123");

This allows you to locate elements relative to other elements on the page instead of fragile absolute xPaths prone to breaking with minor UI changes.

Under the covers, Selenium uses the JavaScript function getBoundingClientRect() to find relative element positions using their size and coordinates.

Let‘s analyze an example to understand the resilience provided:

Version 1

<input id="email" type="email"> 

<input id="pass" type="password">

Locate using:

By.id("pass")

Version 2

<input name="email" type="email">

<input name="password" type="password">  

Locate using:

RelativeLocator.with(By.name("email")).below(By.name("password"))

Here despite changes in element attributes, our relative locator based on position continues to reliably identify the password field.

This prevents lot of maintenance overhead of updating absolute selectors every time UI changes.

Built-in Device Testing

Emulating geo-locations or different device sizes required external tools with Selenium 3.

Selenium 4 comes built-in with Chrome DevTools Protocol support enabling configuration of device parameters directly in tests:

Here are some examples leveraging the DevTools in Selenium:

Override Geo-Location

// Set custom geo-location
DevTools devTools = driver.getDevTools(); 
devTools.send(Emulation.setGeolocationOverride(49.984459, 36.232445));

This allows testing location-aware features without any external providers.

Simulate Mobile Devices

// Emulate iPhone device metrics
Map deviceMetrics = new HashMap() {{
  put("width", 375);
  put("height", 812);
  put("deviceScaleFactor", 3);
  put("mobile", true);  
}};

devTools.send("Emulation.setDeviceMetricsOverride", deviceMetrics);

With this, you can mock mobile or tablet devices eliminating need for separate mobile emulation tools.

Network Condition Simulation

// Simulate Regular 3G network
devTools.send("Network.emulateNetworkConditions", {
  "offline": false,
  "downloadThroughput": 2 * 1024 * 1024 / 8,
  "uploadThroughput": 1 * 1024 * 1024 / 8,
  "latency": 400
});

This allows testing your app performance under real world network conditions.

Thus with Selenium 4, you get all these cross-platform testing capabilities prepacked without needing any external emulation tools!

Migration Best Practices

Now that we understand the new features and capabilities offered in Selenium 4, let‘s consolidate the key steps involved in updating your scripts and frameworks:

Updated Configuration

The DesiredCapabilities class used commonly for browser configuration now gets replaced by ImmutableOptions classes:

Selenium v3:

DesiredCapabilities caps = DesiredCapabilities.chrome();
caps.setCapability("browserVersion", "latest");

Selenium v4:

ChromeOptions options = new ChromeOptions(); 
options.setBrowserVersion("latest");

Here is an option vs capability mapping across browsers:

Browser	Options Class
Chrome	ChromeOptions
Firefox	FirefoxOptions
Edge	EdgeOptions

Make use of the updated Options classes for test configuration.

Migrate Driver Initialization

Change the WebDriver initialization from:

Version 3

WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444"), capability);

Version 4

WebDriver driver = new RemoteWebDriver(new URI("http://localhost:4444"), options);  

Here switch to using URI and Options parameters for driver creation.

Update Grid Node Configuration

For registering nodes with Selenium Grid change:

Version 3:

java -Dwebdriver.chrome.driver=./chromedriver -jar selenium-server-standalone-3.141.59.jar -role node 

Version 4:

java -Dwebdriver.chrome.driver=./chromedriver -jar selenium-server-4.7.2.jar node 

Use the selenium-server-4 standalone JAR for Grid node creation.

Here is an example report indicating migration performance:

Metric	Selenium 3	Selenium 4	Improvement
Test Execution Time (s)	2180	1960	10% Faster
Test Failures	12	3	75% lesser

Summarizing the Upgrade

As we come to the end of this guide, let me quickly summarize the key takeaways:

• Selenium 4 moves to the W3C standard eliminating version-specific custom implementations for more consistent behavior.
• Integrated hub and nodes setup makes distributed testing easier to deploy and scale.
• Relative locators provide more reliable way to identify elements using spatial relationships.
• Embedded dev tools open a range of device testing and debug capabilities without needing external configs.
• Options class over DesiredCapabilities brings more intuitive configuration.

These architectural updates and features help boost both stability, effectiveness and reliability of your test automation framework.

I highly recommend teams to upgrade to Selenium 4 to harness these strengths into your projects. As always having your tests run on real desktop and mobile devices is indispensable to prevent environment gaps. Services like BrowserStack provide instant access to thousands of real mobile and desktop environments to validate your app quality against real-world variability.

Here‘s wishing you best in your Selenium migration journey!