Selenium is one of the most well-known technologies in the software testing space. With built-in support for all major browsers, Selenium is a powerful tool for building automated tests that can be run in a variety of environments.
In order for Selenium to communicate with a browser, the browser needs to implement something called a WebDriver. This is the interface that defines how Selenium can execute various operations within the browser, like clicks and text entries. Each major browser has its own WebDriver implementation that is updated with every major browser release. The communication protocol between the Selenium runtime and the browser’s WebDriver is known as the WebDriver API. The WebDriver API is the only standards-based communication protocol across browsers and is defined in a W3C Spec that is written and updated by representatives from browser vendors, tool vendors, and the open-source community.
This article will discuss WebDriverManager, compare it to another related tool called Selenium Grid, and provide information on how you can use WebDriverManager in your own projects.
Overview
WebDriverManager is an open-source Java library developed by Boni Garcia to enable developers to manage the WebDriver versions within their own testing infrastructure. Instead of having a manual process for downloading, upgrading, and maintaining WebDriver versions, WebDriverManager provides an abstraction that handles these tasks.
WebDriverManager currently supports Chrome, Firefox, Internet Explorer, Opera, Microsoft Edge, and Safari.
Features of Selenium WebDriverManager
The major features provided by WebDriverManager are:
- Driver management: WebDriverManager handles the discovery, download, and installation of the proper WebDrivers for your system architecture and supported browsers.
- Browser finder: Since WebDriverManager v5, each manager has a function called “getBrowserPath()”, which returns an empty object if a particular browser is not installed or the browser path if the system detects the browser. WebDriverManager didn’t support detecting the availability of a browser in the test environment prior to version 5.
- WebDriver builder: Starting with version 5, the WebDriverManager API enables the instantiation of modular
WebDriver objects. Each manager has a
create()
method to create a new instance of WebDriver. - Browsers in Docker: WebDriverManager now provides the ability to generate browser instances inside Docker
containers. A Docker engine must be running in the test environment for this feature to function. The
create()
method must be used in conjunction with the ‘browserInDocker()’ function to download the image from Docker Hub and create a new instance of the ‘WebDriver’ object. - Browser monitoring: Since version 5, WebDriverManager offers easy interaction with the BrowserWatcher extension, which collects information from console logs, captures a video recording of a test, and supports disabling Content Security Policies (CSPs)
Differences between WebDriverManager and Selenium Grid
WebDriverManager and Selenium Grid could easily be confused as they both integrate with Selenium and work with WebDrivers. While Selenium Grid enables remote WebDriver script execution on virtual or physical machines by transferring commands from clients to the browser instances, WebDriverManagers assist in automating the installation, configuration, and execution of WebDrivers in test environments.
WebDriverManager
WebDriverManager performs the following tasks to successfully perform a driver management process:
-
Download: WebDrivers are binary files specific to certain browsers, so it is essential to determine the type and version of the browser. It is also important to know the operating system of the test environment before downloading the WebDriver. In this situation, WebDriverManager can assist in downloading the appropriate WebDriver.
-
Setup: After downloading the appropriate WebDriver to our test environment, setting up could be time-consuming. Traditionally, we manually specify the path of the WebDriver using the ‘System.setProperty’ method, like this:
1
System.setProperty("webdriver.chrome.driver", "/path/to/chromedriver");
After downloading the WebDriver, this procedure is managed automatically by WebDriverManager.
-
Maintenance: Lastly, as time passes, when browser providers update their products, the installed WebDrivers in the test environment might become incompatible with the updated browser versions. When necessary, WebDriverManager upgrades the WebDriver to manage the changes.
Selenium Grid
On the other hand, Selenium Grid addresses a subset of issues concerning distributions and delegations but does not manage the infrastructure for driver management.
The tasks carried out by Selenium Grid include:
- A central entry point for all tests: Selenium Grid uses a hub-node design, where tests only execute from a single system called a hub. The hub serves as the central point where tests run before being forwarded to different Grid nodes.
- Management and control of the nodes/environment where the browsers run: Selenium Grid offers an interface for testing several browsers and operating systems simultaneously on a single hub.
- Scaling: Selenium Grid can be configured to automatically scale up based on the maximum number of sessions per grid and the number of pending environment requests in the session queue.
- Running tests in parallel: Selenium Grid enables parallel testing via a client-server approach, which supports several operating systems and cross-browser testing.
- Cross-platform testing: Selenium Grid works across various system architectures, and supports running tests across all major browsers.
- Load balancing: Selenium Grid was designed to ensure that load distribution across all Nodes is appropriate. Test requests are uniformly distributed from the Hub to the Nodes.
Selenium Grid and WebDriverManager are mostly complementary technologies that can work great together, with WebDriverManager handling the maintenance of WebDriver versions, and Selenium Grid providing utilities for running cross-browser tests at scale.
Configuration
To begin using WebDriverManager, Selenium WebDriver must be installed first in your test environment (machine).
WebDriverManager can be declared in the ‘pom.xml’ file as follows using Maven’s test scope:
|
|
In Gradle, WebDriverManager can be declared as follows:
|
|
Advanced options
The Java API of the WebDriverManager includes configuration. To call desired options, each browser manager utilizes a different function of this API.
WebDriverManager can offer driver binaries for various browsers by calling the “setup()” method on each browser driver manager. The following are some examples for these managers:
|
|
In the example above, we do not specify which driver version should be loaded, and instead rely on WebDriverManager to resolve the appropriate WebDriver version using their resolution algorithm.
We can instead include the version number ourselves. The ‘driverVersion()’ method allows us to specify the exact WebDriver version to use:
|
|
The browserVersion
method can be used to specify which version of the underlying browser (not WebDriver) should be
used. This is useful when you have multiple versions of the same browser installed (such as Chrome and Chrome Canary)
and don’t want to rely on the resolution algorithm to choose the proper version.
|
|
Try Reflect: A modern cross-browser testing platform
Reflect is a no-code testing platform that lets you build and run tests across all popular browsers. Instead of building and maintaining your own infrastructure, using a cloud platform like Reflect allows you to get the benefits of automated cross-browser testing without the headache of maintaining an entire testing grid yourself.