After upgrading to Selenium 4.6 or later, which driver-binary setup code can you delete, and why?

## What Selenium 4.6 added **Selenium 4.6** shipped **Selenium Manager**, a small binary bundled inside the Selenium client itself. Its job is to make sure a suitable browser driver exists before the session starts. When you construct a driver and the client has not been told where a driver executable lives, Selenium Manager resolves one for the browser on the machine and the session proceeds. For a **real-estate listing-filter** suite carried over from Selenium 3, that turns a whole category of setup code into dead weight. The practical effect is that `new ChromeDriver()` works on a machine where nothing was prepared in advance. In Selenium 3 the same line failed unless something — a system property, a checked-in binary on the `PATH`, or a setup call in a base class — had already put a driver where the client could find it. ## What comes out of the suite | Selenium 3 suite carried | Selenium 4.6 and later | |---|---| | `System.setProperty("webdriver.chrome.driver", ...)` in a base class | delete the line | | a driver executable committed into the repository | delete the file | | a third-party driver-manager dependency and its setup call | remove the dependency | | a pipeline step that fetched a driver before the suite ran | remove the step | Each of these was solving the same problem, and the client now solves it. Keeping two of them is worse than keeping either, because the next person to debug a driver mismatch has to work out which one actually ran. ## The order a driver is resolved in 1. If the client has been given an explicit driver location — a system property, or a driver service built with a path — that wins. Explicit configuration is never overridden. 2. Otherwise the client looks for a suitable driver already available on the machine. 3. Otherwise Selenium Manager obtains one that matches the browser that is installed. 4. If none of that succeeds the failure lands at driver construction, before your first navigation, which is where you want it rather than halfway through a listing-filter scenario. Point 1 is the one candidates forget. Selenium Manager is a fallback, not an override — so a machine that must use a specific pinned driver keeps working exactly as it did, and you keep that pin deliberately rather than by accident. ## What is still your problem - **The browser.** Selenium Manager's job is the driver side of the pairing, resolving a driver to match the browser already present. Treat having the browser installed on the machine that runs the session as a separate concern, and do not assume the driver deletion also solved it. - **Environments with no outbound network.** If a machine cannot fetch anything, it still needs a driver present and something pointing at it. That is a legitimate reason to keep an explicit path in exactly one environment and nowhere else. - **The version floor.** Below 4.6 there is no Selenium Manager. Deleting the bootstrap while a runner is still on an earlier 4.x or on Selenium 3 breaks that runner at session construction, and the error will look nothing like a version problem. - **Reproducibility.** Automatic resolution means the driver can differ between two runs on two machines. That is usually what you want for a laptop and sometimes not what you want for a release pipeline; it is a choice to make on purpose. ## Sequencing the deletion The safe order during an upgrade is: get every runner onto **Selenium 4.6 or later** first, confirm a session starts on each of them with the old bootstrap still in place, and only then remove the driver setup. Doing it in the other order gives you two changes failing at once and no way to tell them apart. ```java public WebDriver newListingFilterDriver() { ChromeOptions options = new ChromeOptions(); options.addArguments("--window-size=1440,900"); return new ChromeDriver(options); } ``` That factory is the whole of the driver setup in a migrated suite. There is no path, no property, no downloaded binary and no pre-suite step — and if one environment genuinely needs a pinned driver, the system property is set in that environment alone, which keeps the branch out of the test code entirely. ## Saying it well in an interview Frame it as a deletion, not a feature. The interesting answer is not "Selenium 4.6 added a driver manager"; it is "Selenium 4.6 let us delete the driver bootstrap, the committed binary and a dependency, and the one place we deliberately kept a pinned path is the release pipeline, because we want that run reproducible." That answer shows you know what the feature replaced, what it does not cover, and where you chose not to use it.