Selenium

The shop’s twelve journeys in Selenium on one screen — and who supplies each

Selenium does less than the other two tools on this site, and it does so on purpose. It drives a browser and stops there. So the useful question is who does the rest. Below are the twelve journeys from the End-to-end testing page — the same online shop — as the shop would write them in Selenium. The fourth column says how. The fifth says who supplies it: WebDriver, the standard every browser vendor implements; WebDriver BiDi, its newer two-way channel; the language the tests are written in; or the test environment.

The table answers whether Selenium can run the shop’s journeys. It can, all twelve. The second half of this screen answers a question only Selenium can: do the journeys work in the browsers customers actually installed? Playwright runs builds of its own — its WebKitWebKitSafari’s browser engineThe open-source browser engine behind Safari. A page that works in Chrome can still break in WebKit, which is why test suites run their browser journeys in it too — Playwright ships its own WebKit build for exactly that.All terms is not Safari — which is why the Playwright page leaves journey 2 in the shipped Safari to a person with an iPhone before each release. The run below closes that gap. It is four journeys in five browsers on one grid, every night, written down as the shop’s decisions and numbered so later sections can cite “line 2.3”.

1. 1.What runs

   1. 1.1Journeys 1, 2, 5 and 11 — the four whose outcome depends on how the browser itself treats cookiescookiedata the browser sends backA small piece of data a website asks the browser to keep and send back with every request to that site — which is how a server remembers that you are signed in. Because the browser attaches it automatically, even to a request another site triggered, a session cookie needs its flags set and an anti-forgery check on the server.All terms, frames and other origins. The other eight run in Playwright only.
   2. 1.2Every night and before each release, after the Playwright merge suite is green. A red night never blocks a merge; it opens a ticket.
   3. 1.3In the branded Chrome, Edge and Firefox customers install, in Safari on macOS — and journey 2 also on an iPhone.

2. 2.Where it runs

   1. 2.1One grid inside the shop’s network. The router has a username and password, and no port of it is reachable from the internet.
   2. 2.2Two Linux nodes from the project’s Docker images, with Chrome, Edge and Firefox, four sessions each.
   3. 2.3A Mac mini with one Safari slot, because Safari allows one session at a time, and an iPhone plugged into it — trusted, unlocked, with Remote Automation on. The iPhone shares that one slot.

3. 3.How a session is made and waited on

   1. 3.1A new session for every journey. No session is ever shared between two.
   2. 3.2No implicit wait anywhere. Every wait is explicit: 10 seconds, polled every 250 ms, with a message that names the condition.
   3. 3.3Elements are found by data-testid first and a short CSS selector second. No XPathXPatha path query for page elementsA query language that selects parts of an XML or HTML document by their path through it — this element, inside that one, the third of its kind. In a browser test a long XPath records where an element sits rather than what it is, so it breaks when the layout changes.All terms copied from the browser’s tools.

4. 4.Versions, and when one fails

   1. 4.1Selenium is pinned to an exact version and upgraded in a change of its own. Selenium Manager resolves each driver; the Linux nodes pin browserVersion and move it on purpose.
   2. 4.2A failure keeps a screenshot and the page source, and in Chrome, Edge and Firefox the console log through BiDi. Safari gives the first two and the driver’s own log.
   3. 4.3A red journey is read against Playwright’s result for the same journey. Green there and red here means the browser, not the shop, and the ticket names the browser’s version.

A protocol with three owners, and one round trip per command

Understanding Selenium starts with the fact that it is not one program. Your test calls a binding, the client library in your language. The binding sends each command as an ordinary HTTP request carrying JSONJSONJavaScript Object Notation — text format for dataA text format for passing data around: key–value pairs, lists, numbers and strings. It came out of JavaScript, but every language reads it now, and that is why most APIs answer in it rather than in anything more capable.All terms — to find the pay button, a POST to /session/{id}/element with {"using": "css selector", "value": "[data-testid=pay]"}. A driver, a program written by the browser’s vendor, receives it, makes the browser do it and answers. Every command is a round trip, and nothing comes back that the test did not ask for.

The middle of that chain is a W3C standard: WebDriver became a Recommendation on 5 June 2018, and its next level is a Working Draft, last updated on 2 July 2026. So the chain has three owners. You own the test. The Selenium project owns the bindings, the grid and Selenium Manager, the tool that fetches drivers. The browser vendors own the drivers and the browsers. Because the wire format is public, either end can be swapped, and Apple’s own page says so: tests can be written “in Python, Java, PHP, JavaScript, and any other language whose library is compatible with the W3C WebDriver protocol”.

The driver being the vendor’s is the fact that matters most. Playwright drives Firefox and WebKit through builds it patched itself; a WebDriver driver drives the browser as the vendor ships it. The table is what that means browser by browser.

Waiting is yours to write: what WebDriver checks once, and what it never checks

People who come from Playwright expect a click to wait until clicking makes sense. A WebDriver click does not. The standard’s Element Click scrolls the element into view and checks two things, once. If the element is still out of view, the answer is element not interactable. If something else covers it, the answer is element click intercepted. Either way the error comes back at once; nothing is retried. Navigation waits only until the document’s readyState is “complete”, and an application that renders after that — almost any modern shop — is not waited for at all.

So the shop’s journeys meet the standard’s errors in predictable places, and each error has one fix that works and one that hides it.

Selenium offers two mechanisms for waiting, and only one of them is safe. An implicit wait is a setting for the whole session: every element lookup keeps retrying for up to that long before it fails, and the default is zero. An explicit wait is a loop in the test: it polls a named condition — the element is visible, it is clickable, the text has changed — until the condition holds or the timeout fires, and the timeout message names what was being waited for. The third approach, a fixed sleep, is not a mechanism at all. It is a guess that is too short on a loaded machine and wasted on a fast one.

The second habit that decides whether a suite ages well is how elements are found. A By in Selenium is a locatorlocatorhow a test finds an elementA description of how a browser test finds an element — by role and name, by label, by text or by a test id — resolved again each time it is used. Because it is a recipe rather than a reference, it finds the current element on a page that re-renders, and a good one survives a redesign.Full article →All terms in the full sense: a recipe, resolved each time it is used. What findElement returns is not. It is a reference to one node, and when the page re-renders that node is gone — journey 4’s stale total. So page objectspage objectone class per screen in a test suiteA design pattern for browser tests: each page or component gets a class that knows how to find its elements and perform its actions, so tests read as steps and a redesign is fixed in one place. The class itself should assert nothing — checking the outcome stays in the test.All terms hold By values and find on demand. As for which recipe, the documentation prefers an id where ids are unique and stable, then “a well-written CSS selector”, and it warns that XPath selectors “are typically not performance tested by browser vendors and tend to be quite slow”. The shop adds an attribute for tests (line 3.3): find an element by what it is for, not by where it sits.

A session is a browser — isolation, parallel runs, and the lane one Mac sets

Selenium has no unit of isolation smaller than a session, and a session is a browser process with a fresh profile. The shop opens a new one for every journey (line 3.1). That is why journey 11 is free: a new session cannot see what journey 10 left behind. Every journey pays a browser launch — about two seconds in Chrome on the shop’s nodes, four in Safari, twenty on the iPhone.

A second identity is therefore a second browser. Journey 12 opens one for the agent and has nothing like a saved storage state to start it with. What it has is the cookie. The agent signs in through the APIAPIApplication Programming Interface — contract between programsThe rules one program follows to call another: which requests it may send, in what shape, and what comes back. To the caller it is a contract — everything behind it stays a black box, which is exactly what lets the other side be rewritten without breaking you.Full article →All terms, the test opens a small page on the back office’s domain and adds the session cookie, and from then on the agent is signed in. The order matters: WebDriver refuses a cookie for a domain the browser is not on. With BiDi, storage.setCookie sets one without the detour — in Chrome, Edge and Firefox.

Running tests in parallel is not Selenium’s job either. The test runner does it — JUnit, TestNG, pytest with its parallel plugin, NUnit — and each test opens its own session on the grid. The grid decides how many run at once, through slots: one per processor core for Chrome-family browsers and Firefox on a node, and, the documentation says, “For Safari, only one slot is created.” That one sentence is the shape of the shop’s night.

WebDriver BiDi: the channel the protocol never had — and the browser that does not speak it

Classic WebDriver is request and response, so the browser can never speak first. It cannot say that a request failed, that a script threw an error or that the console printed something. For years the workaround was the Chrome DevTools ProtocolChrome DevTools Protocolhow tools drive ChromeThe protocol Chrome’s developer tools use to inspect and control the browser, open to any program that connects to it. Test tools such as Playwright and Puppeteer drive Chromium through it, so they see the browser’s state directly rather than through the page.All terms, which only Chrome-family browsers speak well. WebDriver BiDi is the standard answer. It adds a WebSocketWebSocketa connection kept open both waysA connection that stays open in both directions: unlike HTTP, the server can send a message on its own without waiting to be asked. Chats and live feeds are built on it, and so is most of what looks like the page updating by itself.All terms to the session, over which the browser sends events as they happen, and it adds commands classic never had. The Selenium documentation describes it as “created by the Selenium project together with the browser vendors” and as “the cross-browser replacement for the Chrome DevTools Protocol”. It is a W3C Working Draft, last updated on 8 October 2026, and a test switches it on with the webSocketUrl capability.

All five work in Chrome and Edge from version 126 — emulation from 137 — and in Firefox. That is the part a plan has to absorb, because the list stops there. As of MDN’s compatibility data of 15 October 2026, Safari supports no part of WebDriver BiDi — the requests to add preload scripts and cookie commands are open in WebKit’s tracker. The browser that is the main reason to run this grid is the one browser on it where the new features do not exist. Everything on the Safari lane uses classic WebDriver: screenshots, page source and the driver’s own log.

Elsewhere the move is already done. Mozilla deprecated its support for the DevTools protocol from Firefox 129, telling users in May 2024 to migrate to BiDi, and Selenium removed its DevTools support for Firefox in 4.29, in February 2025.

Grid: the same protocol with a router in front — and a door that is open by default

Selenium Grid puts a router in front of the same protocol. The test changes one thing, the address it connects to, and the grid decides which machine runs the session. It has six parts, and since Grid 4 each one can run as its own process.

All six can run as one process (standalone), as a hub with nodes, or fully distributed, and the project publishes Docker images for each. What none of those modes changes is the first sentence of the security story.

That sentence is Selenium’s own: “Selenium Grid by default doesn’t have any authentication as the assumption has always been that we want you to put this behind a secure network”. On 25 July 2024 Wiz Research published what happens when it is not. A campaign it named SeleniumGreed was opening sessions on grids exposed to the internet and, in the session’s Chrome options, setting the browser’s binary to Python and its arguments to a script. The node started Python instead of Chrome, the script opened a reverse shell, and the machine was mining cryptocurrency. Wiz counted over 30,000 exposed grids, half of them on the old 3.141.59 and half newer, most on the default port 4444, and confirmed the technique on version 4 as well. Nothing was exploited in the usual sense. A grid runs the program its client asks for — that is its job.

Five changes underneath working suites

A Selenium suite depends on three parties at once: the project, the drivers and the browsers. Each of these changes was announced in advance by the people who made it, and each sorted the suites that let the project manage drivers and pinned versions on purpose from the ones that downloaded binaries by hand.

Where it does not help, and how it compares

Selenium answers a narrower question than it used to. For a new suite with no constraint pushing elsewhere, Playwright does more for less work, and its page says so. Saying it here is what makes the cases where Selenium wins mean something.

• It gives you a browser and nothing else. The runner, the report, the retries, the record of a failed run — a team chooses and wires each one itself.
• Waiting is code you write, and an inherited suite has usually written it wrong.
• Safari under automation starts from a clean slate, like a private window, behind a glass pane. That is close to a first visit, not to a customer with a year of history, and on an iPhone the on-screen keyboard is not shown at all.
• The new features stop where this page’s best argument begins: Safari speaks no BiDi.
• It does not test native apps — Appium does, over the same protocol — and it is not a load testing tool.

Anti-patterns worth naming

• A global implicit wait combined with explicit waits, which the documentation itself warns produces unpredictable wait times.
• Absolute XPath copied out of the browser’s tools, which breaks on the next redesign and explains nothing when it does.
• Assertions inside page objects. The documentation: “Page objects themselves should never make verifications or assertions.”
• One session shared across tests to save launch time, which brings back exactly the order dependency a session was meant to remove.
• A grid on a public port. See SeleniumGreed.
• Code a coding agent wrote from a decade of old posts. Selenium’s own blog, on 29 September 2026, lists what it produces — a DesiredCapabilities object “that hasn’t existed for years, an absolute XPath copied out of DevTools, and a sleep(5)” — and adds: “It will also be describing Selenium 3.”

When to use it

Related pages

• QAPlaywrightPlaywright is an open-source browser automation library and test runner from Microsoft that drives Chromium, Firefox and WebKit from outside the browser. The page opens with the twelve journeys from End-to-end testing written in Playwright — the mechanism each one leans on, and the config that runs them in about four minutes — then covers the one connection everything follows from, the browsers it actually runs, auto-waiting, contexts and workers, what a test can reach besides the page, traces and retries, four changes underneath working suites, and where it does not help.
• QACypressCypress is an open-source test runner for web applications that runs the test inside the browser, in the same tab and event loop as the application. The page opens with the twelve journeys from End-to-end testing as the shop would write them in Cypress — seven native, five that need a workaround, and the one thing all five have in common — then covers the tab and the four trade-offs Cypress calls permanent, the command queue, retry-ability as it has worked since Cypress 12, isolation and the Node side, parallelism by spec file, four changes underneath working suites, and where it does not help.
• QAEnd-to-end testingEnd-to-end testing walks a business process through the assembled system from start to finish, the way a customer would, in conditions close to production. The page opens with one shop’s whole suite — twelve journeys, the seam only each one proves, and what is real and what is replaced — then covers what no lower level can prove, the shapes a portfolio takes, what a red journey costs, how to choose journeys and keep them trustworthy, and three failures where a test stopped one step short.