In Selenium 4, what actually happens when a Java test calls new ChromeDriver()?

juniormust knowfreq 85%

answer

One line, several moving parts
Something starts before the browser does
A port on the loopback interface
Then an HTTP request creates something
The reply carries an identifier

basics

~20 s

Constructing ChromeDriver starts a local driver process, waits for it to listen on a free loopback port, then sends it a new-session request. The driver launches the browser and replies with a session id that every later command carries.

solid answer

~40 s

In Selenium 4, new ChromeDriver() starts a driver process as a child of the test process, waits until it is listening on a free loopback port, then sends it the new-session command with the capabilities requested. The driver launches the browser and replies with a session id; the constructor stores that id and returns, so an open browser window on a blank page already exists before driver.get(...) runs. Every later command is another HTTP request to that same port, addressed to that session id. ChromeDriver, FirefoxDriver, EdgeDriver and SafariDriver all behave this way and all extend RemoteWebDriver; the remote class skips the local process and talks to a URL instead.

In Selenium 4, `new ChromeDriver()` starts a driver process as a child of the test process, waits until it is listening on a free loopback port, then sends it the new-session command with the capabilities requested. The driver launches the browser and replies with a session id; the constructor stores that id and returns, so an open browser window on a blank page already exists before `driver.get(...)` runs. Every later command is another HTTP request to that same port, addressed to that session id. `ChromeDriver`, `FirefoxDriver`, `EdgeDriver` and `SafariDriver` all behave this way and all extend `RemoteWebDriver`; the remote class skips the local process and talks to a URL instead.

code

java · 14 lines

java

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

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

go deeper

for a junior

Be ready to name, in order, what the constructor does: starts a driver process, waits for a bound port, sends a new-session request, receives a session id, and leaves an open browser window on a blank page.

for a middle

Explain that client and driver speak HTTP over a loopback port the driver chose, and that the browser is a third process that neither the test nor the driver runs inside. Say why the line blocks.

for a senior

Show that construction is treated as the slowest and most environment-dependent step of a run, and that a failure on this line is diagnosed as setup rather than chased through the test body.

for a principal

Own the resource arithmetic: every construction is a process, a bound port and a browser's memory footprint, and that unit is what a team's run capacity is planned around.

The line under the microscope

In Selenium 4 the statement WebDriver driver = new ChromeDriver(); looks like an ordinary object allocation, and it is not one. By the time that constructor returns, a separate operating-system process is running on the test machine, it is listening on a TCP port, an HTTP request has crossed to it, a real browser window is open, and the test holds a session id that every later command will carry. A suite that fills in a conference talk-submission form usually spends more wall-clock time on that one line than on the navigation that follows it.

The sequence, in order

The constructor starts a driver process — for Chrome, the chromedriver binary — as a child of the test process.
That process binds a free port on the loopback interface and begins serving HTTP there; the client polls that address until it answers, which is why the line blocks.
The client sends the new session command, POST /session, to that address, carrying the capabilities describing the browser it wants.
The driver launches the browser itself and waits until it is controllable.
The driver replies with a session id and the capabilities it actually granted; the client stores the id and the constructor returns.

Only after step 5 can driver.get("https://cfp.example.com/submit-talk") do anything, and that call is simply the next HTTP request to the same port, addressed to the session id from step 4.

What you are holding when it returns

A live browser session — a window already exists, on a blank page, before the test navigates anywhere.
A session id: an opaque string the driver chose, not the client, scoping every later command.
An object declared as WebDriver but actually a ChromeDriver, which extends RemoteWebDriver — the very class used to talk to a driver on another host.
A child process, plus a browser process, that stay alive until the session ends.

The local classes and their remote counterpart

Constructor	What it starts on the test machine	Where the browser runs
`new ChromeDriver()`	a Chrome driver process on a loopback port	the test machine
`new FirefoxDriver()`	a Firefox driver process on a loopback port	the test machine
`new EdgeDriver()`	an Edge driver process on a loopback port	the test machine
`new SafariDriver()`	the Safari driver process, macOS only	the test machine
`new RemoteWebDriver(url, options)`	nothing — it opens an HTTP connection to the URL	wherever that URL answers

The four local classes differ only in which browser they manage; each is a RemoteWebDriver underneath, which is why the test code written on top of them is identical.

Why the shape matters

Construction is a setup step that can fail. A test throwing on this line never reached an assertion; it is an environment failure, not a product defect.
It is not free. A process start, a port bind and a browser launch take seconds, not milliseconds, so the number of constructions in a run is a real cost.
Nothing is in-process. The test never calls into the browser; it sends HTTP to the driver, which drives the browser by its own means. That is why a debugger cannot step into a click.
The order is fixed. The port must answer before the new-session request can be sent, and the session must exist before any command can be addressed.

java

WebDriver driver = new ChromeDriver();
driver.get("https://cfp.example.com/submit-talk");

The second line is not the beginning of the browser's life; it is already the second command of an established session.

What the constructor does not do

It does not navigate. The session opens on a blank page; the talk-submission form is not loaded until it is asked for.
It does not hand back a half-built object. If the driver never answers on its port, or declines the session, the line throws instead of returning something unusable.
It does not give two browsers. One constructor call means one session and one browser to drive.

Where candidates go wrong

Describing the constructor as merely creating an object, with the browser opening on the first get.
Believing the client library drives the browser directly, with no separate process between them.
Assuming the client invents the session id and tells the driver to use it.
Forgetting the loopback port entirely, which makes every later question about remote endpoints impossible to answer.

## The line under the microscope In Selenium 4 the statement `WebDriver driver = new ChromeDriver();` looks like an ordinary object allocation, and it is not one. By the time that constructor returns, a separate **operating-system process** is running on the test machine, it is listening on a TCP port, an HTTP request has crossed to it, a real browser window is open, and the test holds a **session id** that every later command will carry. A suite that fills in a conference talk-submission form usually spends more wall-clock time on that one line than on the navigation that follows it. ## The sequence, in order 1. The constructor starts a **driver process** — for Chrome, the `chromedriver` binary — as a child of the test process. 2. That process binds a **free port on the loopback interface** and begins serving HTTP there; the client polls that address until it answers, which is why the line blocks. 3. The client sends the **new session** command, `POST /session`, to that address, carrying the capabilities describing the browser it wants. 4. The driver launches the browser itself and waits until it is controllable. 5. The driver replies with a **session id** and the capabilities it actually granted; the client stores the id and the constructor returns. Only after step 5 can `driver.get("https://cfp.example.com/submit-talk")` do anything, and that call is simply the next HTTP request to the same port, addressed to the session id from step 4. ## What you are holding when it returns - A **live browser session** — a window already exists, on a blank page, before the test navigates anywhere. - A **session id**: an opaque string the driver chose, not the client, scoping every later command. - An object declared as `WebDriver` but actually a `ChromeDriver`, which extends `RemoteWebDriver` — the very class used to talk to a driver on another host. - A **child process**, plus a browser process, that stay alive until the session ends. ## The local classes and their remote counterpart | Constructor | What it starts on the test machine | Where the browser runs | |---|---|---| | `new ChromeDriver()` | a Chrome driver process on a loopback port | the test machine | | `new FirefoxDriver()` | a Firefox driver process on a loopback port | the test machine | | `new EdgeDriver()` | an Edge driver process on a loopback port | the test machine | | `new SafariDriver()` | the Safari driver process, macOS only | the test machine | | `new RemoteWebDriver(url, options)` | nothing — it opens an HTTP connection to the URL | wherever that URL answers | The four local classes differ only in which browser they manage; each is a `RemoteWebDriver` underneath, which is why the test code written on top of them is identical. ## Why the shape matters - **Construction is a setup step that can fail.** A test throwing on this line never reached an assertion; it is an environment failure, not a product defect. - **It is not free.** A process start, a port bind and a browser launch take seconds, not milliseconds, so the number of constructions in a run is a real cost. - **Nothing is in-process.** The test never calls into the browser; it sends HTTP to the driver, which drives the browser by its own means. That is why a debugger cannot step into a click. - **The order is fixed.** The port must answer before the new-session request can be sent, and the session must exist before any command can be addressed. ```java WebDriver driver = new ChromeDriver(); driver.get("https://cfp.example.com/submit-talk"); ``` The second line is not the beginning of the browser's life; it is already the second command of an established session. ## What the constructor does not do - It does not navigate. The session opens on a blank page; the talk-submission form is not loaded until it is asked for. - It does not hand back a half-built object. If the driver never answers on its port, or declines the session, the line throws instead of returning something unusable. - It does not give two browsers. One constructor call means one session and one browser to drive. ## Where candidates go wrong - Describing the constructor as merely creating an object, with the browser opening on the first `get`. - Believing the client library drives the browser directly, with no separate process between them. - Assuming the client invents the session id and tells the driver to use it. - Forgetting the loopback port entirely, which makes every later question about remote endpoints impossible to answer.

After the constructor returns, how does the test code actually reach the driver?
Over HTTP to the loopback port the driver bound. Each API call on the driver object becomes a request to that address, addressed to the session id the driver returned, and the reply is parsed back into a Java value.
What is different if the test constructs FirefoxDriver instead?
The shape is the same: a driver process, a bound port, a new-session request, a session id. Only the driver process and the browser differ. Both classes extend `RemoteWebDriver`, so test code declared as `WebDriver` needs no change at all.
Is a browser window open before the first get() call?
Yes. The new-session reply means the browser is already launched and controllable, sitting on a blank page. `driver.get(...)` only navigates an existing session; it never creates one.

It is less like calling a method and more like hiring a switchboard operator: the operator has to be running and answering on their own line before you can ask them to open anything for you.

saying these in an interview costs you the question

Says the constructor only creates a Java object and opens nothing
Thinks the client library drives the browser directly, with no process between
Believes the browser opens only when get() is first called
Cannot say that the driver listens on a local HTTP port
Assumes the client library generates the session id itself

In Selenium 4, what actually happens when a Java test calls new ChromeDriver()?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The line under the microscope

The sequence, in order

What you are holding when it returns

The local classes and their remote counterpart

Why the shape matters

What the constructor does not do

Where candidates go wrong

▾common follow-ups3 questions

▾analogy~20 s

▾red flags5 flags

The line under the microscope

The sequence, in order

What you are holding when it returns

The local classes and their remote counterpart

Why the shape matters

What the constructor does not do

Where candidates go wrong

answer

go deeper