WebDriverManager: the part of your Selenium setup that is not Selenium

One library, one job: resolving a driver binary before the test starts

The description line reads 'Automated driver management and other helper features for Selenium WebDriver in Java', and that is an accurate summary of a library with 2692 stars and 690 forks. The core claim in the README is that WebDriverManager carries out the management, meaning download, setup and maintenance, of the drivers Selenium WebDriver requires, such as chromedriver, geckodriver and msedgedriver, in a fully automated manner.

The mechanism is one builder-style call. You select a manager for the browser you want, `chromedriver()` for Chrome in the README's example, and invoke `setup()`. That is the entire contract, and the README shows it inside a JUnit 5 test class:

class ChromeTest {

    WebDriver driver;

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

The second entry point collapses both halves into a line. The README offers `create()` to manage the driver and instantiate the `WebDriver` object in a single call, which is how the `ChromeCreateTest` example assigns `driver = WebDriverManager.chromedriver().create();` in its `@BeforeEach`. If your suite already constructs its drivers directly, `setup()` is the drop-in form; if you would rather not construct them at all, `create()` is the shorter form.

Neither call is magic. They resolve a driver version, put it where the driver launcher can find it, and hand control back to your code. Everything past that is your test.

Beyond driver setup: browser discovery and Docker containers

The description says 'and other helper features', and two of them are named explicitly. The first is the capability to discover browsers installed on the local system. That matters more than it sounds: a machine with several Chrome or Firefox installations, or none in the default location, is a common cause of a driver that resolves but refuses to start.

The second is running browsers in Docker containers, described as a feature available in WebDriverManager 5. The requirement is a Docker Engine on the machine running the tests. The call is `browserInDocker()` combined with `create()` on a given manager, and the README spells out what happens: WebDriverManager pulls the image from Docker Hub, starts the container and instantiates the WebDriver object to use it.

The Docker example is where the library stops being a downloader and starts being a session manager, because it also handles teardown. The test class configures the manager once as a field, with `browserInDocker().enableVnc().enableRecording()`, then calls `wdm.quit()` in `@AfterEach` instead of `driver.quit()`. Recording the session and remote access through noVNC are switches on that same builder.

So the value of the Docker path is not isolation, it is reproducibility plus observability. A fixed image plus a recorded video is a much easier artifact to hand to someone who did not write the test.

The repository is small, and the documentation moved away from it

The file tree is nine entries: `.github/`, `CHANGELOG.md`, `LICENSE`, `README.md`, `docker/`, `docs/`, `pom.xml`, `src/` and `.gitignore`. There is no bundled example module, no sample project and no scripts directory. This is a library repository rather than a tutorial repository.

That is a deliberate choice, and the README states it plainly: as of version 5, the documentation has moved to the project's site at bonigarcia.dev/webdrivermanager. The README's Documentation section says that site contains all the features, examples, configuration and advanced capabilities. The Driver Management section then does the honest thing and closes with a pointer: for the driver resolution algorithm and the configuration capabilities, read the documentation.

So the driver resolution algorithm, which is the interesting part of any such library, is not described in the repository at all. Neither are the cache directory, proxy handling, mirror selection, offline mode or version pinning, all of which are configuration topics the site is said to cover. A `docs/` directory exists in the tree, but the README does not claim it as the reference.

The practical consequence: you can evaluate whether the API shape suits you from the README in two minutes, and you cannot evaluate whether the resolution behaviour suits you without leaving the repository.

Maven coordinates, Java 8 baseline and the quality gates

The Maven Central badge names the coordinates as `io.github.bonigarcia:webdrivermanager`, which matters because there are several projects with similar names and different languages. The topic list includes chromedriver, geckodriver, java, maven, selenium, selenium-webdriver, webdriver and docker, and the related search terms around it turn up Python and C# libraries of the same name, so matching the group and artifact exactly is the first thing to get right.

The Java baseline is stated in a badge: JDK 8. That is older than most new projects target, and it is the sort of choice a library makes deliberately when it expects to live inside large enterprise build setups.

The rest of the badge row is a short list of the project's process commitments. There is a build status badge for GitHub Actions, a SonarCloud quality gate, a codecov coverage badge, an Apache 2.0 license badge, a Stack Overflow support tag, and Open Collective backer and sponsor badges. The Support section confirms the Open Collective relationship and defines the two tiers, a personal donation or recurring contribution as a backer, and a recurring contribution by a company as a sponsor.

For a dependency that fetches binaries during a build, the interesting operational fact is that open issues stands at zero while forks sit at 690, nearly a quarter of the star count. That pattern usually means downstream teams are carrying local adjustments rather than filing public issues.

Release history: 6.3.3, 6.3.4, 6.4.0, all with empty bodies

Three releases are recorded. `webdrivermanager-6.3.3` was published on 2025-11-08, `webdrivermanager-6.3.4` on 2026-04-02, and `webdrivermanager-6.4.0` on 2026-09-23. The cadence is roughly five to six months, which fits a library that has to track browser release cycles rather than a library shipping features continuously.

All three release bodies are empty strings. That is unusual enough to name rather than gloss over, and it has a practical consequence: there is nothing in the tags themselves that tells you what changed. The detailed history lives in `CHANGELOG.md` at the root, and the 6.4.0 tag went out on the same day the repository itself was pushed, at 10:45 against a push at 10:46.

So if you are deciding whether to upgrade, the two places to look are the changelog file and the diff between tags, not the release page. With zero open issues and a version that has been current since September, an upgrade is unlikely to be urgent, and the risk of a surprise is correspondingly low.

One more number worth carrying: 6.4.0 is a minor bump, not a major one, so the API described in the README, `setup()`, `create()` and the Docker builder, should still be the API you get.

Where this library stops and Selenium takes over

The clearest way to read this project is as a precondition step for Selenium rather than a replacement for it. Every example in the README still imports `org.openqa.selenium.WebDriver` and `org.openqa.selenium.chrome.ChromeDriver`, still instantiates a real driver, and still calls `driver.quit()`. Nothing in this library changes how you write assertions, locate elements or structure a test.

What it removes is the maintenance work around the driver version matching the browser version. In a manual setup that work is a person remembering to download a binary when Chrome updates. Here it is a call that runs before the browser starts.

The honest caveat is that this shifts rather than removes the dependency. The library now has to know where to get drivers, which means network access at test time on a fresh machine unless a cache already exists, and it adds a moving part to the build. Teams that want zero network access at test time will point it at a local cache or a mirror, and that configuration is on the documentation site, not in the README.

For a small suite on a developer laptop, `WebDriverManager.chromedriver().setup()` is a clear win. For a large build running hundreds of browser tests in containers, the Docker path with recording is the more interesting half of the library, and the one that changes how you debug a failure afterwards.

Editorial conclusion

WebDriverManager earns its place in a Java test suite the moment driver maintenance becomes your problem rather than your build system's. The API surface is three calls in the common case, `chromedriver().setup()`, `chromedriver().create()` and `browserInDocker()`, and the repository is a clean Maven project with a `pom.xml`, a `docker/` directory, a `CHANGELOG.md` and a code coverage badge. What it does not do is answer the questions a team usually has on day one: cache locations, proxy behaviour, mirror configuration and version pinning all live at bonigarcia.dev/webdrivermanager, and the README says so in one sentence. Version 6.4.0 shipped on 2026-09-23 with an empty release body, so the changelog file and the tag timestamps are where the release cadence is visible.

Frequently asked questions

Official sources

1. bonigarcia/webdrivermanager on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases