In Selenium 4, what happens when you construct a ChromeDriver without configuring any chromedriver path?

juniormust knowfreq 74%

answer

Something has to find the executable first
The client already ships it
Bundled since a 4.x release
Detects the browser, then resolves a driver
Selenium Manager, invoked implicitly

basics

~20 s

Selenium Manager runs automatically. The binary bundled in the Selenium 4 client detects the installed Chrome, works out the matching chromedriver, downloads it if the local cache lacks it, and returns the path, so the session starts with no PATH entry and no setup code.

solid answer

~40 s

Since Selenium 4.6, a binary called Selenium Manager ships inside the client itself. When you write new ChromeDriver() and no driver executable has been configured, the client runs that binary as a subprocess: it detects the installed browser, determines the matching driver, reuses a cached copy or downloads one into ~/.cache/selenium, and prints the absolute path back. The client then starts the driver process at that path and the new-session request proceeds as normal. That is why a Selenium 4 project needs no chromedriver on the PATH, no webdriver.chrome.driver property, and no third-party driver-manager dependency in the build — all three were the pre-4.6 answer to the same problem. It is a resolution step only; the session, the options and the teardown behave exactly as they always did.

Since **Selenium 4.6**, a binary called **Selenium Manager** ships inside the client itself. When you write `new ChromeDriver()` and no driver executable has been configured, the client runs that binary as a subprocess: it detects the installed browser, determines the matching driver, reuses a cached copy or downloads one into `~/.cache/selenium`, and prints the absolute path back. The client then starts the driver process at that path and the new-session request proceeds as normal. That is why a Selenium 4 project needs no chromedriver on the PATH, no `webdriver.chrome.driver` property, and no third-party driver-manager dependency in the build — all three were the pre-4.6 answer to the same problem. It is a resolution step only; the session, the options and the teardown behave exactly as they always did.

code

java · 15 lines

java

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class StatementDownloadTest {

    public static void main(String[] args) {
        WebDriver driver = new ChromeDriver();
        try {
            driver.get("https://bank.example.com/statements");
            System.out.println(driver.getTitle());
        } finally {
            driver.quit();
        }
    }
}

go deeper

for a junior

Be able to say that Selenium 4 finds and downloads the driver for you, that the component is called Selenium Manager, and that it means no PATH entry and no setup call before creating the driver.

for a middle

Explain the sequence: no configured path, so the client runs the bundled binary, which detects the browser, resolves a matching driver, uses the cache or downloads, and returns a path.

for a senior

Show you know when to opt out. Explain that automatic resolution is a convenience with a network dependency, and that an explicitly configured executable is the alternative on hosts where that dependency is unacceptable.

for a principal

Frame it as a setup-cost decision across many repositories: whether teams rely on automatic resolution, provision drivers themselves, or run both, and what each choice costs in onboarding time and reproducibility.

What the constructor really does

A suite that opens a bank statement-download page starts with something as plain as new ChromeDriver(). That single line hides two separate jobs. The second is the one everyone knows: send a new-session request to a driver process and get a session back. The first is the one Selenium 4 quietly took over: find a driver process to talk to at all.

Before a session can exist there must be an executable on disk — chromedriver for Chrome, geckodriver for Firefox — that the client can launch. Supplying that executable used to be the test author's problem. From Selenium 4.6 it is the client's, and the component that does it is Selenium Manager.

Where Selenium Manager comes from

It is a binary bundled inside the Selenium client, not a library you add, a service you run, or a tool you install.
Because it ships with the client, upgrading Selenium upgrades it; there is no separate version to track in the build file.
It is invoked implicitly — only when no driver executable has been configured. Configure one and it is never consulted.
It runs as a short-lived subprocess, does its work, prints a path and exits. It is not part of the session and does nothing while the test runs.

The steps between the constructor and the session

The client finds no configured driver executable, so it runs the bundled Selenium Manager binary.
Selenium Manager detects the installed browser and the version it reports.
It determines which driver build matches that browser.
It looks in the local driver cache, ~/.cache/selenium by default, and downloads the driver only if no matching copy is there.
It prints the resolved absolute path; the client launches that executable and sends the new-session request.

On a second run against an unchanged machine, step 4 is a cache hit and the whole sequence costs milliseconds.

What it replaced

Concern	Before Selenium 4.6	From Selenium 4.6
Getting a driver	Download it yourself, or add a third-party driver manager such as WebDriverManager to the build	Bundled Selenium Manager resolves it
Telling the client where it is	Put it on the `PATH`, or set `webdriver.chrome.driver`	Nothing to set
A new machine	Reproduce that setup before the first test can run	Clone and run
Extra dependencies	One more test-scope library to keep current	None; it ships with the client

The interview question behind this leaf is usually phrased as what did Selenium Manager replace? The honest answer names all three of those rows: manual PATH placement, the driver-path system property, and the third-party driver-manager libraries teams used instead of both.

What it does not do

It does not change the session in any way; capabilities, ChromeOptions, waits and teardown are untouched.
It does not remove the need to quit() — the driver process it located still has to be stopped by the test.
It does not run at all when the driver executable is configured explicitly, so a project can opt out per run.
It is a resolution step, not a runtime component: once the path is printed, it is out of the picture.

Where candidates go wrong

Saying the driver is downloaded on every run. It is cached; a matching cached driver is reused.
Believing a third-party driver-manager dependency is still required in a Selenium 4 build. It is not, and leaving one in place means two mechanisms compete to solve the same problem.
Thinking Selenium Manager is a separate download or a service. It is inside the client already.
Assuming it starts the browser. It resolves a driver path; the driver starts the browser, exactly as before.

For the statement-download suite this is the difference between a README with four setup steps and a project a new engineer can clone and run. The suite's own code is unchanged by any of it: the same get, the same locators, the same quit() in a finally block. Only the question of where the driver executable came from has moved from the reader of the README into the client library — which is precisely why interviewers ask this as a screening question, and why the expected answer names both the mechanism and the three older practices it retired.

## What the constructor really does A suite that opens a bank statement-download page starts with something as plain as `new ChromeDriver()`. That single line hides two separate jobs. The second is the one everyone knows: send a **new-session** request to a driver process and get a session back. The first is the one Selenium 4 quietly took over: *find a driver process to talk to at all*. Before a session can exist there must be an executable on disk — `chromedriver` for Chrome, `geckodriver` for Firefox — that the client can launch. Supplying that executable used to be the test author's problem. From **Selenium 4.6** it is the client's, and the component that does it is **Selenium Manager**. ## Where Selenium Manager comes from - It is a **binary bundled inside the Selenium client**, not a library you add, a service you run, or a tool you install. - Because it ships with the client, upgrading Selenium upgrades it; there is no separate version to track in the build file. - It is invoked **implicitly** — only when no driver executable has been configured. Configure one and it is never consulted. - It runs as a short-lived subprocess, does its work, prints a path and exits. It is not part of the session and does nothing while the test runs. ## The steps between the constructor and the session 1. The client finds no configured driver executable, so it runs the bundled Selenium Manager binary. 2. Selenium Manager **detects the installed browser** and the version it reports. 3. It determines which **driver build** matches that browser. 4. It looks in the local **driver cache**, `~/.cache/selenium` by default, and downloads the driver only if no matching copy is there. 5. It prints the resolved absolute path; the client launches that executable and sends the new-session request. On a second run against an unchanged machine, step 4 is a cache hit and the whole sequence costs milliseconds. ## What it replaced | Concern | Before Selenium 4.6 | From Selenium 4.6 | |---|---|---| | Getting a driver | Download it yourself, or add a third-party driver manager such as WebDriverManager to the build | Bundled Selenium Manager resolves it | | Telling the client where it is | Put it on the `PATH`, or set `webdriver.chrome.driver` | Nothing to set | | A new machine | Reproduce that setup before the first test can run | Clone and run | | Extra dependencies | One more test-scope library to keep current | None; it ships with the client | The interview question behind this leaf is usually phrased as *what did Selenium Manager replace?* The honest answer names all three of those rows: manual PATH placement, the driver-path system property, and the third-party driver-manager libraries teams used instead of both. ## What it does not do - It does not change the **session** in any way; capabilities, `ChromeOptions`, waits and teardown are untouched. - It does not remove the need to `quit()` — the driver process it located still has to be stopped by the test. - It does not run at all when the driver executable is configured explicitly, so a project can opt out per run. - It is a **resolution** step, not a runtime component: once the path is printed, it is out of the picture. ## Where candidates go wrong - Saying the driver is downloaded on **every** run. It is cached; a matching cached driver is reused. - Believing a third-party driver-manager dependency is still required in a Selenium 4 build. It is not, and leaving one in place means two mechanisms compete to solve the same problem. - Thinking Selenium Manager is a separate download or a service. It is inside the client already. - Assuming it starts the browser. It resolves a driver path; the driver starts the browser, exactly as before. For the statement-download suite this is the difference between a README with four setup steps and a project a new engineer can clone and run. The suite's own code is unchanged by any of it: the same `get`, the same locators, the same `quit()` in a `finally` block. Only the question of *where the driver executable came from* has moved from the reader of the README into the client library — which is precisely why interviewers ask this as a screening question, and why the expected answer names both the mechanism and the three older practices it retired.

How would you stop Selenium Manager from being invoked for a particular run?
Configure the driver executable yourself. Build the service with `ChromeDriverService.Builder().usingDriverExecutable(...)`, or set the `webdriver.chrome.driver` system property. Selenium Manager is only consulted when no path has been configured, so supplying one takes it out of the run completely.
Does Selenium Manager download the driver every time the suite runs?
No. It looks in a local driver cache, `~/.cache/selenium` by default, before downloading anything. A matching cached driver is reused, so only the first run on a machine — or a run needing a driver the cache does not hold — pays for a download.
Your project still declares a third-party driver-manager dependency. What would you do with it?
Remove it. On Selenium 4.6 and later the bundled Selenium Manager solves the same problem, and keeping both means two mechanisms decide which driver the run uses. Dropping the dependency shortens the build and leaves one clear answer to where the driver came from.

saying these in an interview costs you the question

Says a chromedriver must still be on the PATH in Selenium 4
Thinks the driver is downloaded fresh on every single run
Describes Selenium Manager as a separate tool you install
Claims a third-party driver-manager dependency is still required
Believes Selenium Manager starts the browser rather than resolving a driver

In Selenium 4, what happens when you construct a ChromeDriver without configuring any chromedriver path?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the constructor really does

Where Selenium Manager comes from

The steps between the constructor and the session

What it replaced

What it does not do

Where candidates go wrong

▾common follow-ups3 questions

▾red flags5 flags

What the constructor really does

Where Selenium Manager comes from

The steps between the constructor and the session

What it replaced

What it does not do

Where candidates go wrong

answer

go deeper