Introduction to WebDriverManager

1. Introduction

The purpose of web automation in Java is simple. In essence, the idea is to open a browser and interact with a web page. However, an immediate challenge appears from the browser itself, namely, the binary compatibility. To elaborate, each browser requires a corresponding driver binary, and that binary must match the installed browser version. Even a small mismatch leads to runtime errors. WebDriverManager in Java addresses this issue by automating driver management in Java-based Selenium projects.

In this tutorial, we’ll introduce WebDriverManager. First, we’ll explore the purpose and need for this driver. Subsequently, we’ll look at how to include WebDriverManager in the code. Lastly, we’ll discuss integrating WebDriverManager with different libraries.

2. What Is WebDriverManager?

WebDriverManager is a Java library that automatically resolves, downloads, and configures browser drivers required by Selenium. Instead of manually managing binaries and system properties, the library handles these steps programmatically. It determines which browser version is installed, finds the correct driver version, downloads it if necessary, and configures the system so Selenium can use it.

Notably, Selenium includes a built-in tool called Selenium Manager, which also automates driver management. Selenium Manager removes the need to manually download browser drivers. However, WebDriverManager is an enhanced alternative with additional features, such as driver caching control, support for Dockerized browsers, and flexibility in complex environments.

A traditional Selenium setup requires explicitly specifying the driver path in the code. For instance, for a Chrome browser, we set the driver using setProperty:

System.setProperty("webdriver.chrome.driver", "/path/to/chromedriver");
WebDriver driver = new ChromeDriver();

This approach works initially but doesn’t scale well. Every time the browser updates, the corresponding driver should also be updated manually. In shared environments such as CI/CD pipelines or team projects, maintaining consistent driver versions becomes difficult. Moreover, hardcoded paths make the code less portable across systems.

In addition, WebDriverManager removes this burden by handling driver resolution dynamically. It also caches downloaded drivers locally, so repeated executions don’t trigger unnecessary downloads. As a result, test execution becomes both faster and more reliable.

To use WebDriverManager, we should include it as a dependency in the XML file.

For Maven, we use the <dependency> tag:

<dependency>
    <groupId>io.github.bonigarcia</groupId>
    <artifactId>webdrivermanager</artifactId>
    <version>6.3.3</version>
    <scope>test</scope>
</dependency>

For Gradle, we use dependencies:

dependencies {
    testImplementation("io.github.bonigarcia:webdrivermanager:6.3.3")
}

This ensures the library is available during test execution without affecting production builds.

3. Using WebDriverManager

In this example, we look at a basic way to use WebDriverManager for a simple call:

import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class SimpleWebDriver {

     public static void main(String[] args) {

          WebDriverManager.chromedriver().setup();

          WebDriver driver = new ChromeDriver();
          driver.get("https://google.com");

          driver.quit();
}
}

In the example above, WebDriverManager.chromedriver() creates a manager instance specifically for Chrome. This instance hides all logic required to handle ChromeDriver binaries.

To explain the code further, calling .setup() triggers the resolution process:

1. 1. Inspect the system to detect the installed Chrome version.
   2. Determine the compatible driver version.
   3. Download the correct driver version if not already cached.
   4. Set the appropriate system property webdriver.chrome.driver.

Because of this, the subsequent line of ChromeDriver() works without any manual configuration.

In addition, driver.get() opens the desired URL, and driver.quit() closes the browser and releases resources.

4. Using WebDriverManager With Different Libraries

In this section, we explore how WebDriverManager integrates with JUnit for structured test execution and how it supports multiple browsers through a consistent interface. Furthermore, we also explore how it extends into more advanced use cases such as generic driver instantiation and browser detection.

4.1. Using WebDriverManager With JUnit

In professional test environments, it’s considered best practice to perform setup operations once per test class rather than repeating them before every individual test. WebDriverManager fits into this pattern when combined with JUnit 5’s @BeforeAll annotation:

import io.github.bonigarcia.wdm.WebDriverManager;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class GoogleTest {

    @BeforeAll
    static void setupClass() {
        WebDriverManager.chromedriver().setup();
    }

    @Test
    void testGoogle() {
        WebDriver driver = new ChromeDriver();
        driver.get("https://www.google.com");
        driver.quit();
    }
}

The @BeforeAll annotation guarantees that the setupClass() method is executed exactly once before any test methods in the class run. By calling WebDriverManager.chromedriver().setup() at this stage, the framework downloads and configures the correct ChromeDriver binary ahead of time, so that later tests don’t need to repeat this process. This avoids redundant driver resolution for each test case. Once the setup is complete, each individual test method can focus on browser interactions, navigating to a URL, and quitting the driver.

4.2. Working With Multiple Browsers

One of the strengths of WebDriverManager is its ability to manage drivers for multiple browsers using the same consistent pattern. Rather than writing separate setup logic for each browser, the library provides dedicated manager methods that follow an identical structure regardless of which browser is being targeted:

// Firefox
WebDriverManager.firefoxdriver().setup();
WebDriver driver = new org.openqa.selenium.firefox.FirefoxDriver();

// Microsoft Edge
WebDriverManager.edgedriver().setup();
WebDriver driver = new org.openqa.selenium.edge.EdgeDriver();

Each method returns a browser-specific manager object that handles the resolution and configuration of the appropriate driver binary for that browser.

4.3. Generic Manager Usage

One of the scenarios for generic manager usage is when we don’t know the type of target browser at compile time.

For example, when the browser type is passed as a runtime parameter, or it is read from a configuration file, we use WebDriverManager to determine the appropriate manager dynamically:

import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class GenericExample {
    public static void main(String[] args) {
        WebDriverManager.getInstance(ChromeDriver.class).setup();

        WebDriver driver = new ChromeDriver();
        driver.get("https://example.com");
        driver.quit();
    }
}

In the code above, the getInstance(ChromeDriver.class) call accepts a driver class as its argument and uses it to identify and return the correct manager at runtime. This means the same line of code can resolve the manager for any supported browser simply by swapping out the class reference. In practice, this is useful in parameterized or data-driven test frameworks where the browser type is injected from an external source.

5. Conclusion

In this article, we began with a basic introduction to WebDriverManager. We also discussed how to use this driver for Selenium automation. Lastly, we explored how to use this driver with various libraries.

To conclude, WebDriverManager simplifies Selenium automation by eliminating manual driver management. Instead of handling downloads, version compatibility, and configuration, projects can rely on a single method call to perform all setup tasks. This assists in maintaining a clean code, fewer runtime errors, and improved maintainability.

The source code is available over on GitHub.