Getting Started with Selenium ChromeDriver for Automated Testing

session not created: This version of ChromeDriver only supports Chrome version 114.

If you’ve automated anything in a browser, you’ve met that message. For most of Selenium’s life it was practically a rite of passage: Chrome silently updates itself overnight, your pinned ChromeDriver binary is now one major version behind and every test in the suite dies at session start on a Tuesday for no reason connected to your code. Whole CI pipelines have gone red on this. Teams wrote cron jobs just to re-download drivers.

And here’s the part that makes half the tutorials on this subject a trap for beginners: that problem was largely fixed years ago and the fix ships inside Selenium itself. Any guide still walking you through downloading ChromeDriver from a website, matching the version number to your browser and adding the executable to your PATH is teaching the workflow from before Selenium 4.6. You’ll still find that guide ranking on page one. You just shouldn’t follow it.

What ChromeDriver is, in one honest paragraph

Selenium can’t talk to a browser directly. Each browser has a driver, a small separate program that translates Selenium’s commands, click this, type here, navigate there, into the browser’s own automation protocol and ChromeDriver is that translator for Chrome. Your test script talks to ChromeDriver, ChromeDriver drives Chrome and the reason Chrome gets the most attention is boring and sufficient: it’s where most of your users are, so it’s where your tests have to be.

The version coupling is tight by design, the driver speaks to the internals of one specific Chrome major version, which is precisely why the auto-update problem was so relentless. Chrome updated every few weeks whether your test infrastructure was ready or not.

The modern setup, which is shorter than the old one

Since Selenium 4.6, a component called Selenium Manager comes along inside Selenium and quietly handles the whole driver question. It detects your installed Chrome, fetches the matching driver, caches it and refreshes it when Chrome moves. The modern setup in Python is genuinely this:

from selenium import webdriver

options = webdriver.ChromeOptions()
options.add_argument("--headless=new")

driver = webdriver.Chrome(options=options)
driver.get("https://example.com")
print(driver.title)
driver.quit()

No path. No download step. No version bookkeeping. Java and C# behave the same way through their package managers, Maven or NuGet pulls Selenium and driver management rides along. Google also now publishes Chrome for Testing, dedicated browser builds that don’t auto-update, made specifically because the normal Chrome’s self-updating habit and stable test environments were never compatible ideas. If your CI still pins driver binaries by hand, moving to this pair of changes deletes an entire category of maintenance.

The headless flag in that snippet deserves one sentence: headless means Chrome runs with no visible window, which is what you want in CI where there’s no screen anyway and the “new” headless mode behaves much closer to real Chrome than the old one did, so screenshots and layout-dependent tests come out more trustworthy.

The three habits that separate stable suites from flaky ones

Wait for conditions, never for time. A hard sleep is a guess about how slow the app will be and every guess is either wasted seconds or a random failure. Explicit waits, hold until this element is clickable, until this text appears, adapt to reality. Nearly every mysteriously intermittent Selenium failure I’ve seen traces back to timing assumptions and moving a suite off sleeps is the single highest-value refactor available in this field.

Screenshot on failure, automatically. A red test with no picture is an argument; a red test with a screenshot is a diagnosis. Selenium takes screenshots natively, wire it into your test framework’s failure hook once and it pays forever, especially for the failures that only happen on the CI machine at 3am.

Extract the repeated flows. Logging in, reaching a page, filling the standard form, these become functions or a page object layer if the suite is serious. The suites that rot are the ones where a login flow is copy-pasted into forty tests and then the login page changes.

Reporting rounds this out. TestNG or Allure on top of the suite turns a wall of console output into something a human can act on and parallel execution is how large suites keep their run times humane, though parallelism is exactly where shared state between tests comes back to punish you, so it’s a reward for well-isolated tests rather than a bolt-on fix.

The Safari question, since Chrome is never actually the whole job

Selenium’s cross-browser promise is real, the same test drives Firefox through GeckoDriver and Edge through it’s own driver by changing little more than the driver class. Safari is the awkward one. People still search for Safari for Windows and the plain answer is that Apple discontinued it back in 2012, so there is no local way to run Safari tests from a Windows machine. Safari’s driver exists only on macOS, where it ships with the system.

Which makes Safari coverage an infrastructure question rather than a code question. A Mac in the corner works. More commonly, teams run it through a cloud grid, LambdaTest executes Selenium suites across Safari, Chrome, Firefox and Edge on a few thousand environment combinations, BrowserStack and Sauce Labs are the other two names in every comparison and for the specific Safari-from-Windows problem any of the three is the honest answer, since the alternative is buying hardware to test one browser. The same platforms also solve the quieter version of the problem, old Chrome versions your enterprise users refuse to leave behind, which your auto-updated local Chrome can no longer even show you.

One caution that belongs in every Selenium article and appears in almost none: test credentials and payment flows are still real secrets. Suites that log into things should pull credentials from a secrets manager, not the repo and anything touching payment gateways belongs in sandbox mode, because a test suite that leaks a password into CI logs has automated exactly one thing.

Start with the eight-line snippet above against your own app’s login page, add an explicit wait, make it fail once on purpose to see the screenshot hook work. That’s day one and it’s a better day one than any version-matching tutorial ever offered, mostly because you’ll spend it on your app instead of on ChromeDriver’s release archive.