skip to content

In Selenium automation, what is Chrome for Testing and why point a session at it instead of the installed Chrome?

level: middleimportance: nice to knowfreq 38%

answer

  1. A browser that will not move underneath you
  2. Published for automation, not for browsing
  3. Each build ships a matching driver
  4. Two settings, two different files
  5. Deliberately behind the current channel

basics

~20 s

Chrome for Testing is a Chrome distribution published for automation that never updates itself, with a matching driver published for every build. Pointing at it keeps browser and driver on one version, so a run stays reproducible.

solid answer

~40 s

**Chrome for Testing** is a Chrome distribution published for automation that never updates itself, and a `chromedriver` with the same version number is published for every build. Pointing a Selenium 4 session at it — `ChromeOptions.setBinary(...)` for the browser, `ChromeDriverService.Builder().usingDriverExecutable(...)` or `webdriver.chrome.driver` for the driver — means the two halves stay on one version until you move them, so the seat-map suite that is green today is still green next month for the same reason. The everyday Chrome install cannot do that: it auto-updates on its own schedule, its path varies by machine, and it is shared with the person using the machine. The cost is that a pinned build is deliberately behind the current channel.

code

java · 23 lines
java
import org.openqa.selenium.HasCapabilities;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

public class PinnedSeatMapBrowser {

  public static void main(String[] args) {
    String home = "/opt/cft/141.0.7390.54";
    System.setProperty("webdriver.chrome.driver", home + "/chromedriver");

    ChromeOptions options = new ChromeOptions();
    options.setBinary(home + "/chrome");

    WebDriver driver = new ChromeDriver(options);
    try {
      System.out.println(((HasCapabilities) driver).getCapabilities().getBrowserVersion());
      driver.get("https://example.com/flights/FL482/seat-map");
    } finally {
      driver.quit();
    }
  }
}

go deeper

for a junior

Be ready to say what it is: a Chrome build published for automated runs that does not auto-update, downloaded to a path you choose rather than installed for everyday browsing.

for a middle

Explain the mechanics you would wire up: which setting names the browser executable, which names the driver executable, and why one version string should build both paths.

for a senior

Argue the tradeoff in production terms. A pinned pair makes a red run mean something, but it drifts from the current channel, so demonstrate how and when you move it and how each run records its pair.

for a principal

Own the policy: how far behind the current browser the organisation is willing to run, who reviews a version bump, and what evidence a release needs about the browser versions its checks actually ran on.

## What Chrome for Testing is **Chrome for Testing** is a Chrome distribution published by the Chrome team specifically for automated runs. Its defining property is negative: it does **not** update itself. You download a numbered build, put it somewhere you control, and it stays that version until you replace it. A `chromedriver` carrying the same version number is published alongside every build, so the matching pair is always obtainable — which is precisely what a suite driving an airline seat map needs, because `ChromeDriver` refuses a session whose Chrome major is not its own. ## Why the everyday install is a poor automation target - It **auto-updates** on its own schedule, so the browser half of your pair moves without anybody deciding it should. - It is shared with the human using the machine, whose profile, extensions and pending update prompt are not part of your test environment. - Its location varies by machine and platform, so "the installed Chrome" is not a thing a suite can name reliably. - You cannot choose its version, so you cannot reproduce last month's run, and you cannot deliberately hold two versions side by side. - When it moves, the seat-map suite fails at session creation with a message about a version nobody chose. | | Everyday Chrome install | Chrome for Testing | |---|---|---| | Updates | silently, on Chrome's schedule | never; you replace the directory yourself | | Version choice | whatever the channel is on today | any published build you name | | Location | platform-specific, varies per machine | a path you decide and can hard-code | | Matching driver | you go looking for one | published with the same version number | | Shared with a human | yes, profile and all | no, it exists for the run | ## Wiring one into a Selenium session In Selenium 4 the browser half is chosen with `ChromeOptions.setBinary(...)`, which takes the path to the executable the driver should launch; the driver half is chosen with `ChromeDriverService.Builder().usingDriverExecutable(...)` or the `webdriver.chrome.driver` system property. Those are two different settings for two different files, and confusing them is the most common wiring mistake: ```java ChromeOptions options = new ChromeOptions(); options.setBinary("/opt/cft/141.0.7390.54/chrome"); System.setProperty("webdriver.chrome.driver", "/opt/cft/141.0.7390.54/chromedriver"); ``` 1. Name one version string and use it to build both paths, so the two halves cannot be edited apart. 2. Confirm the session really used the build you meant by reading `Capabilities.getBrowserVersion()` from the first driver you create. 3. Upgrade by changing that one version string, downloading the new pair, and running the seat-map suite once before the change is merged. ## What the pin does not buy you - It does not tell you the seat map still works in the browser your passengers are running today; a pinned build is deliberately behind the current channel, and someone has to decide when to move it. - It does not cover other browsers. Edge and Firefox have their own drivers and their own version rules, and pinning Chrome says nothing about them. - It does not remove the need to read the failure. If the pinned browser and the pinned driver are edited apart, you get the same `only supports Chrome version` refusal you were trying to avoid. - It does not make the pinned build immortal. A version you never move eventually stops resembling anything users have, which is a scheduling decision, not a technical one. ## How a pinned pair still drifts apart Pinning is a discipline, not a switch, and there are three ways the seat-map suite ends up refused again: - Somebody edits the browser path to a newer directory and leaves the driver path alone, so the two halves are back on different majors. - A machine keeps an older `chromedriver` earlier on `PATH`, or a leftover `webdriver.chrome.driver` value in a run configuration, and that copy wins over the pinned one. - The pinned directory is deleted or never provisioned on a new machine, and the session silently falls back to whatever browser that machine happens to have. Each of those is visible in the same way: the version the session reports is not the version you pinned, which is why reading it back on the first session is worth the two lines it costs. ## When the everyday install is fine Driving the browser already on your own machine is perfectly reasonable while you are writing a new seat-map test and watching it run. The moment the run has to be repeatable — by a colleague, by a machine, or by you in three months when a defect report says "it passed then" — the version of the browser becomes part of the answer, and only a build that cannot move underneath you can supply it.

  • If the suite only ever drives a pinned build, does anything check the browser real users run?
    No, and that is the accepted cost. The pin buys a repeatable seat-map run; keeping up with what passengers actually use is a separate, deliberate exercise against a newer pair. The point is that moving the pin becomes a reviewed change rather than something the browser does to you overnight.
  • Where do you keep the pinned version so the browser and driver paths cannot drift apart?
    In one constant or property that both paths are built from, so a bump is a single edit. If a reviewer sees only one of the two paths change, that is the defect: the halves have been edited apart, and the next run will be refused at session creation.

saying these in an interview costs you the question

  • Thinks Chrome for Testing is a different rendering engine
  • Passes the browser path to the driver-executable setting
  • Believes a pinned build still updates itself quietly
  • Assumes pinning Chrome also pins Firefox and Edge
  • Says a pin removes the need to ever upgrade