What changes when a Selenium suite swaps new ChromeDriver() for RemoteWebDriver against a URL?

seniorshould knowfreq 55%

answer

One of them starts nothing locally
Same interface, different construction
A URL replaces what a class implied
Every command becomes a network hop
One class extends the other

basics

~20 s

Only construction changes. The remote form starts no process locally, takes a reachable URL plus capabilities naming the browser, and makes every command a network round-trip. The command set, the session id and the test code stay identical.

solid answer

~40 s

In Selenium 4 ChromeDriver extends RemoteWebDriver, so the swap changes construction only. The local class starts a driver process and points itself at the loopback port that process bound; RemoteWebDriver starts nothing and needs two things the class name used to imply — a reachable URL, and capabilities naming the browser, since there is no longer a class to infer it from. Afterwards both are the same object: same W3C commands, same session id, same test code. What differs in practice is cost and failure mode. Every command becomes a network round-trip rather than a loopback one, so a chatty test pays latency per command; and the first thing that can fail is reaching the URL rather than starting a local process.

In Selenium 4 `ChromeDriver` extends `RemoteWebDriver`, so the swap changes construction only. The local class starts a driver process and points itself at the loopback port that process bound; `RemoteWebDriver` starts nothing and needs two things the class name used to imply — a reachable URL, and capabilities naming the browser, since there is no longer a class to infer it from. Afterwards both are the same object: same W3C commands, same session id, same test code. What differs in practice is cost and failure mode. Every command becomes a network round-trip rather than a loopback one, so a chatty test pays latency per command; and the first thing that can fail is reaching the URL rather than starting a local process.

code

java · 19 lines

java

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.remote.RemoteWebDriver;

import java.net.URI;
import java.net.URL;

class TalkFormDrivers {

    static WebDriver local() {
        return new ChromeDriver();
    }

    static WebDriver remote() throws Exception {
        URL endpoint = URI.create("http://webdriver.example.internal:5555").toURL();
        return new RemoteWebDriver(endpoint, new ChromeOptions());
    }
}

go deeper

for a junior

Know that both constructors give back a WebDriver and that the remote one needs a URL. Be able to say that the local class starts something on your machine and the remote class does not.

for a middle

Explain the inheritance and what it implies: the same command set and session either way, with construction as the only place the two differ. Say what the remote form must be told explicitly.

for a senior

Demonstrate that you have moved a real suite across this boundary: the latency arithmetic per command, the filesystem no longer being shared, and the different first failure to expect.

for a principal

Own the position that where the browser runs is a construction-time decision the codebase should absorb once, so the suite is not written twice, and be able to argue what that portability is worth.

Two constructors, one interface

In Selenium 4, new ChromeDriver() and new RemoteWebDriver(url, options) both hand back something a test can declare as WebDriver, and a suite that fills in a conference talk-submission form can be pointed at either without changing a single step. The two are not siblings: ChromeDriver extends RemoteWebDriver. The local class is the remote class plus one extra job — starting a driver process on the test machine and pointing itself at the loopback port that process bound.

What stays identical

The command set. Both speak the same WebDriver commands over HTTP; there is no separate remote protocol.
The session. Both constructors end in a new-session request and a session id that scopes every later command.
The test code. get, findElement, waits, screenshots — unchanged, because the whole difference lives in construction.
The failure vocabulary. The same exception types come back from both once an endpoint is answering.

What the remote constructor needs that the local one infers

The class name ChromeDriver carries two facts implicitly: which browser is wanted, and where the driver is. RemoteWebDriver carries neither, so both must be supplied:

A URL — a reachable HTTP endpoint with a driver already listening. Nothing starts on the test machine; if that address does not answer, construction fails before a session was ever requested.
Capabilities, passed as the options object the constructor takes, naming the browser the remote end should give back. Without them the remote end has nothing to act on.

Side by side

	`new ChromeDriver()`	`new RemoteWebDriver(url, options)`
Starts a process locally	yes, a driver process	no
Binds a local port	yes, on loopback	no
Where the browser runs	the test machine	the host behind the URL
Browser chosen by	the class constructed	the capabilities sent
Per-command transport	a loopback round-trip	a network round-trip
First thing that can fail	the driver process or its port	reaching the URL

What it costs in a real run

A single talk-submission test may issue hundreds of commands: one per find, one per click, one per attribute read, one per wait poll. On loopback the transport is negligible; across a network each command carries real latency, and the total is latency multiplied by command count, not latency once. The practical consequences:

A suite that felt fast locally can slow noticeably when the browser moves, with no code change at all.
Chatty patterns — re-finding the same field, polling tightly — get proportionally more expensive than compact ones.
The browser's filesystem is no longer the test's. A path the test can see is not a path the remote browser can open, and anything the browser writes lands on the other host.
Anything read back over the wire, such as a screenshot, is now a payload crossing a network rather than a copy on the same machine.

Failure looks different too

Locally, the first thing that can go wrong is a process on the test machine that never came up, or a port that never answered. Remotely, it is reachability: name resolution, routing, a closed port, or an address that answers with something that is not a driver. Once the endpoint does answer, the two converge again — a refusal to create the session surfaces as SessionNotCreatedException either way, carrying the remote end's own message.

java

WebDriver local = new ChromeDriver();

URL endpoint = URI.create("http://webdriver.example.internal:5555").toURL();
WebDriver remote = new RemoteWebDriver(endpoint, new ChromeOptions());

Both variables are used identically for the rest of the run. That is the point of the inheritance: where the browser lives is decided once, at construction, and never referred to again.

A common misreading

Because the local class hides its driver process, people assume the remote one hides one too, and go hunting for a stray process on their own machine when a remote run fails. There is none — RemoteWebDriver starts nothing locally. The reverse mistake is just as common: believing a local run is somehow direct, when it is already client-to-driver HTTP, merely over a very short wire. Seeing that a local driver is a remote driver with a shorter wire is exactly what makes the two interchangeable in a suite.

## Two constructors, one interface In Selenium 4, `new ChromeDriver()` and `new RemoteWebDriver(url, options)` both hand back something a test can declare as `WebDriver`, and a suite that fills in a conference talk-submission form can be pointed at either without changing a single step. The two are not siblings: `ChromeDriver` **extends** `RemoteWebDriver`. The local class is the remote class plus one extra job — starting a driver process on the test machine and pointing itself at the loopback port that process bound. ## What stays identical - **The command set.** Both speak the same WebDriver commands over HTTP; there is no separate remote protocol. - **The session.** Both constructors end in a new-session request and a **session id** that scopes every later command. - **The test code.** `get`, `findElement`, waits, screenshots — unchanged, because the whole difference lives in construction. - **The failure vocabulary.** The same exception types come back from both once an endpoint is answering. ## What the remote constructor needs that the local one infers The class name `ChromeDriver` carries two facts implicitly: *which browser* is wanted, and *where the driver is*. `RemoteWebDriver` carries neither, so both must be supplied: 1. A **URL** — a reachable HTTP endpoint with a driver already listening. Nothing starts on the test machine; if that address does not answer, construction fails before a session was ever requested. 2. **Capabilities**, passed as the options object the constructor takes, naming the browser the remote end should give back. Without them the remote end has nothing to act on. ## Side by side | | `new ChromeDriver()` | `new RemoteWebDriver(url, options)` | |---|---|---| | Starts a process locally | yes, a driver process | no | | Binds a local port | yes, on loopback | no | | Where the browser runs | the test machine | the host behind the URL | | Browser chosen by | the class constructed | the capabilities sent | | Per-command transport | a loopback round-trip | a network round-trip | | First thing that can fail | the driver process or its port | reaching the URL | ## What it costs in a real run A single talk-submission test may issue hundreds of commands: one per find, one per click, one per attribute read, one per wait poll. On loopback the transport is negligible; across a network each command carries real latency, and the total is **latency multiplied by command count**, not latency once. The practical consequences: - A suite that felt fast locally can slow noticeably when the browser moves, with no code change at all. - Chatty patterns — re-finding the same field, polling tightly — get proportionally more expensive than compact ones. - The browser's filesystem is no longer the test's. A path the test can see is not a path the remote browser can open, and anything the browser writes lands on the other host. - Anything read back over the wire, such as a screenshot, is now a payload crossing a network rather than a copy on the same machine. ## Failure looks different too Locally, the first thing that can go wrong is a process on the test machine that never came up, or a port that never answered. Remotely, it is reachability: name resolution, routing, a closed port, or an address that answers with something that is not a driver. Once the endpoint does answer, the two converge again — a refusal to create the session surfaces as `SessionNotCreatedException` either way, carrying the remote end's own message. ```java WebDriver local = new ChromeDriver(); URL endpoint = URI.create("http://webdriver.example.internal:5555").toURL(); WebDriver remote = new RemoteWebDriver(endpoint, new ChromeOptions()); ``` Both variables are used identically for the rest of the run. That is the point of the inheritance: where the browser lives is decided once, at construction, and never referred to again. ## A common misreading Because the local class hides its driver process, people assume the remote one hides one too, and go hunting for a stray process on their own machine when a remote run fails. There is none — `RemoteWebDriver` starts nothing locally. The reverse mistake is just as common: believing a local run is somehow direct, when it is already client-to-driver HTTP, merely over a very short wire. Seeing that a local driver is a remote driver with a shorter wire is exactly what makes the two interchangeable in a suite.

If ChromeDriver already extends RemoteWebDriver, why does the local class exist at all?
For the one job the base class does not do: starting the driver process for that browser and pointing the client at the port it bound. It also fixes the browser, so no URL and no browser name have to be supplied at the call site.
Why does a remote construction need capabilities when a local one can be argument-free?
Because the class name is the only place a local construction states the browser, and `RemoteWebDriver` has no such name. The remote end learns which browser is wanted only from the capabilities the constructor sends with the new-session request.
A remote run is slower but the tests are unchanged. Where did the time go?
Into transport, multiplied by command count. Each find, click, read and wait poll is a separate request, so per-command latency that was negligible on loopback becomes the dominant cost once the browser is on another host.

saying these in an interview costs you the question

Thinks RemoteWebDriver also starts a driver process locally
Believes remote sessions use a different command set than local ones
Assumes the class name still picks the browser on a remote endpoint
Ignores that every command becomes a separate network round-trip
Expects files on the test machine to be visible to a remote browser

What changes when a Selenium suite swaps new ChromeDriver() for RemoteWebDriver against a URL?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two constructors, one interface

What stays identical

What the remote constructor needs that the local one infers

Side by side

What it costs in a real run

Failure looks different too

A common misreading

▾common follow-ups3 questions

▾red flags5 flags

Two constructors, one interface

What stays identical

What the remote constructor needs that the local one infers

Side by side

What it costs in a real run

Failure looks different too

A common misreading

answer

go deeper