What’s New in Selenium 4.11.0?

Selenium has been an instrumental tool in the world of web testing, evolving with the times to offer better, more streamlined testing solutions. In its recent update, Selenium 4.11.0 brings significant enhancements, particularly in the Selenium Manager feature. This edition presents two pivotal advancements: the support of Chrome for Testing (CfT) endpoints for chromedriver management and the pioneering approach to automated Chrome management based on CfT. In this article, we will delve deep into these new features, providing clarity on their relevance and utility.

Background

Before diving into the nuances of 4.11.0, it’s imperative to understand the backstory. Introduced in version 4.6.0, the Selenium Manager became an integral part of all Selenium releases, spanning across Java, JavaScript, Python, Ruby, and .Net. Crafted in Rust, this binary tool is primarily oriented towards automated driver management for Selenium.

Though still in its beta phase, Selenium Manager has been gradually establishing itself as a significant facet of the Selenium suite. With its core strength being automated driver management, it’s quickly proving its mettle, aiding testers in keeping pace with the dynamic realm of browsers and their respective drivers. You can perform Selenium automation tests with https://www.lambdatest.com/selenium.

Features of Selenium Manager

Source: perfecto.io

Automated Driver Management:

Selenium Manager’s most lauded attribute is the Automated Driver Management. A term not merely restricted to downloading; it encompasses a series of pivotal steps:

  • Browser Version Discovery: One of its primary tasks involves identifying the version of the browser installed on the system executing Selenium. For instance, it can detect versions for browsers like Chrome, Firefox, and Edge using specific shell commands.
  • Driver Version Discovery: Upon ascertaining the browser version, Selenium Manager then determines the corresponding driver version. This determination is based on online metadata maintained by respective browser vendors such as chromedriver, geckodriver, and msedgedriver.
  • Driver Download: After identifying the apt driver version, the Manager fetches the URL for the driver and proceeds to download, uncompress, and store the driver locally.
  • Driver Cache: To optimize the process, the uncompressed driver binaries are stored in a local cache folder. This cache ensures that if the same driver is needed subsequently, it’s sourced from this cache, accelerating the setup process.
  • Drivers on the PATH: Selenium Manager’s integration is elective. Users have the flexibility to either manage their drivers manually or rely on other third-party tools. However, in scenarios where a driver isn’t provided, the Selenium Manager springs into action. It also aids in pinpointing any issues with the drivers on the PATH, proving its utility beyond just driver management.

Importance of Driver Management

Source: balkans.aljazeera.net

However, why is such a system needed? Consider a commonplace scenario: A tester manually manages the chromedriver for Selenium tests, with Chrome’s stable version being 113. So, the tester fetches chromedriver 113. All seems well until the evergreen nature of Chrome comes into play.

Chrome’s ‘evergreen’ trait allows it to auto-upgrade silently to the succeeding stable version when available. Although beneficial for end-users, this can be a stumbling block for automated testing. In our example, the local Chrome may update to version 115 over time, making the previously downloaded driver incompatible. The resulting mismatch can halt test processes, a problem that Selenium Manager aims to prevent.

Such instances underline the importance of driver managers like Selenium Manager. With the 4.11 version, it’s equipped to diagnose potential problems with drivers on the PATH, showcasing warnings to testers when an incompatibility is detected.

Chrome for Testing (CfT) Introduction

2024 saw the Chrome team unveil a promising initiative for testers – Chrome for Testing (CfT). Distinguished from the regular Chrome, CfT is a trimmed-down version targeting testing requirements.

While the standard Chrome version adopts the evergreen mechanism, CfT offers a more controlled environment. It enables testers to pin browsers for Selenium  testing, curbing the automatic updates that can disrupt test flows. Further, CfT versions are available as portable binaries, compatible with major operating systems and spanning across stable, beta, dev, and canary channels. The convenience gets amplified as these versions can be programmatically discerned using the CfT JSON endpoints.

A pivotal shift came when, post version 114, the chromedriver team ceased the publishing of chromedriver releases and metadata using their conventional repositories. Hence, from version 115 onwards, chromedriver releases are exclusively available through the CfT JSON endpoints. This transition has immense implications for driver managers, compelling them to adapt. Fortunately, Selenium Manager is already compatible with this new chromedriver discovery method, ensuring that those employing Selenium Manager with Chrome should switch to Selenium 4.11.0 to continue smooth automated chromedriver management.

Automated Browser Management using CfT

Source: espreso.co.rs

When considering the realm of browser testing, synchronizing browser versions with their respective drivers is a critical task. Chrome for Testing (CfT) introduced a game-changing methodology for automated browser management.

How Selenium Manager Uses CfT Endpoints for Chromedriver Management

Selenium Manager taps into the potential of CfT by leveraging its JSON endpoints. These endpoints provide detailed information about various Chrome versions, their corresponding drivers, and their direct download links. Instead of depending on the conventional repositories, Selenium Manager now sources chromedriver data directly from the CfT endpoints, ensuring that the fetched drivers are always compatible with the browser versions.

Real-World Scenarios

Imagine a setup where the testing environment hosts multiple versions of Chrome – Stable, Beta, and Dev. With the evergreen nature of Chrome, these can update frequently and independently. A significant challenge testers face is managing the chromedrivers corresponding to these dynamic versions. This is where Selenium Manager, with its CfT integration, steps in. By continually referencing the CfT endpoints, it can seamlessly detect the right driver for any given Chrome version and manage its download, ensuring smooth test executions.

Another scenario is the introduction of the browserVersion browser option. This option is a godsend for testers. It grants the ability to specify which browser version to use during tests. When this is set, the Selenium Manager, powered by the CfT endpoints, fetches the right chromedriver for the specified browser version, completely automating the driver management process.

You can use a cloud based testing platform. That allows you to run Selenium testing on 3000+ test environments including real device cloud, to test your websites on multiple real world scenarios.

Deep Dive: Under the Hood

Source: vijesti.me

For those inclined towards the technicalities, understanding how Selenium Manager functions can be intriguing.

Technical Insights and Implementation Details

Selenium Manager, crafted in Rust, uses a combination of shell commands and HTTP requests. For driver discovery, it sends requests to the CfT JSON endpoints, parsing the response to extract metadata about the latest chromedrivers and their associated Chrome versions.

For browser management, Selenium Manager identifies the system’s browser version using shell commands. With this information, it queries the CfT endpoints to ascertain the right driver, downloads it, and caches it locally.

Use Cases

Scenario 1: A firm has a dynamic testing environment where testers frequently switch between Chrome’s stable and beta channels. With the Selenium Manager, there’s no need for manual interventions. It identifies the active Chrome version and ensures its compatibility with the right chromedriver, all sourced from the CfT endpoints.

Scenario 2: Consider a CI/CD pipeline where tests are run in containers. Each container may host different Chrome versions. The Selenium Manager, integrated into the test suite, ensures that every container gets the right chromedriver, fostering uninterrupted test flows.

Troubleshooting

Source: optikalucic.com

Facing hiccups while using the Selenium Manager? The key lies in effective troubleshooting.

Enabling Logging

Logs can provide critical insights into any anomalies. Through Selenium bindings, users can activate logging for the Selenium Manager. Depending on the language binding you’re using (like Java, Python, etc.), there’s usually a configuration or method to enable detailed logging.

Directing Users

While logs are invaluable, sometimes the solution might need a deeper dive. The Selenium troubleshooting page is an extensive resource, housing solutions to common issues and offering guidelines to resolve unprecedented ones.

Taking Advantage of Selenium manager with Selenium 4.11

One of the most prominent features is the Selenium Manager’s Automated Driver Management. The Selenium Manager works diligently behind the scenes every time the WebDriver gets instantiated. Once a WebDriver command, such as new ChromeDriver(); is executed, the Selenium Manager springs into action by following a systematic approach.

How it Works:

  1. Browser Version Discovery: Selenium Manager first identifies the browser version installed on the user’s system. In the case of the Chrome browser, the command google-chrome –version assists in this discovery.
  2. Driver Version Discovery: After deducing the browser version, Selenium Manager taps into online metadata maintained by browser vendors like ChromeDriver or geckodriver. This metadata helps the Manager determine the appropriate driver version compatible with the identified browser version.
  3. Driver Download: Subsequently, the Manager downloads the driver binary using the URL fetched from the earlier step. It unzips and stores this binary locally for direct access.
  4. Driver Cache: To optimize efficiency, all driver binaries are stored in a local cache (~/.cache/selenium). This caching ensures that the same driver does not need to be redownloaded when future tests run on that particular browser/driver version.

Conclusion

Selenium 4.11.0, with its innovative Selenium Manager powered by CfT endpoints, is a milestone in automated web testing. As browsers evolve and their management complexities rise, tools like Selenium Manager become indispensable. The ability to automate driver management, catering to diverse Chrome versions, underpins the essence of what Selenium strives for: seamless, efficient, and accurate web testing. Migrating to this version is not just beneficial – it’s imperative.