Selenium review: alternatives, tutorial and pricing

Your test code calls a language binding, and the binding sends each instruction, such as new session, find element or click, as an HTTP request to a driver process. The driver translates it into browser-specific commands. Drivers come from the browser vendors: ChromeDriver from the Chromium project, geckodriver from Mozilla, msedgedriver from Microsoft and safaridriver from Apple. Because the wire format is a W3C specification, a binding only has to speak HTTP and JSON, which is why Selenium has official clients in five languages and why the same test can target any browser whose vendor ships a conforming driver. It is also why behaviour occasionally differs between browsers: each driver is a separate implementation of the same standard.

Selenium Manager is a command-line tool written in Rust and shipped inside every binding since 4.6. When you start a session without pointing at a driver, the binding calls it to detect the installed browser version, download the matching driver and cache it under ~/.cache/selenium. Since 4.11 it also manages browsers: set browserVersion to a number, or to a label such as beta, and it downloads Chrome for Testing, Firefox or Edge if that version is not installed. It is a fallback rather than a takeover, so a driver you supply on the PATH still wins. One exception: installing Edge on Windows needs administrator rights.

Each command is a separate request and response, even on localhost, so a test making a hundred element lookups pays a hundred round trips. Navigation waits for document.readyState to reach complete under the default page load strategy, but nothing else does: scripts that render content after load, spinners and buttons that enable later are invisible to the protocol. Selenium offers two mechanisms. An implicit wait, which defaults to 0, makes every element lookup poll for a while. An explicit wait polls for a specific condition. The documentation warns against mixing them, because a 10 second implicit wait inside a 15 second explicit wait can time out after 20 seconds.

Selenium Grid 4 is a set of components, a router, distributor, session map, new session queue and event bus, plus nodes that host browsers. They can run together in one process (standalone, started with java -jar selenium-server-<version>.jar standalone on Java 11 or later), as hub and nodes, or fully distributed. Tests connect to the router with a RemoteWebDriver, and the distributor places each session on a node that matches the requested capabilities. Grid does not make tests parallel. It provides the capacity that your test runner, whether TestNG, JUnit, NUnit or pytest-xdist, has to actually request by opening several sessions at once.

Classic WebDriver only answers questions; it cannot tell you that something happened. WebDriver BiDi, a W3C protocol the Selenium project designed with the browser vendors, adds a WebSocket so the browser can stream events such as network requests, console messages and JavaScript errors. You enable it per session with the webSocketUrl capability, or options.enable_bidi = True in Python. BiDi is the cross-browser replacement for the Chrome DevTools Protocol, which Selenium also exposes but only for Chromium browsers. Coverage is still growing: the release notes for 4.49 to 4.51 are full of BiDi work in individual bindings, so check your language’s documentation before designing around a feature.

Keep three layers apart. A fixture in conftest.py owns the driver: it reads configuration from the environment, so the same tests run headless in CI, headed on a laptop or against a Grid, and it always quits. Page objects own locators and the waits for their own page, so a test reads as user intent and a markup change touches one class. Tests own assertions only. Prefer a dedicated data-test attribute agreed with developers over XPath copied from dev tools, and keep explicit waits inside page object methods rather than scattered through tests. Leave the implicit wait at its default of 0, so the only waiting in the suite is waiting you can see.

A Selenium pipeline is an ordinary pipeline for your language: check out, install, run. GitHub’s Ubuntu runners include Chrome, and if a browser is missing Selenium Manager downloads Chrome for Testing, so no driver setup step is needed. pytest-xdist runs test files across the runner’s cores with -n auto, which only works if tests share no state and each gets its own driver from a function-scoped fixture. Write a JUnit XML report for the CI summary, and upload screenshots from failed tests as an artefact so a red build can be diagnosed without a re-run. Pin Selenium in requirements.txt so a new release never changes behaviour in the middle of a sprint.

When one machine is not enough, or you need browsers the CI image does not have, point the same fixture at a Grid by setting SELENIUM_REMOTE_URL. The quickest Grid is a docker-selenium standalone container; give it 2 GB of shared memory, as the image documentation advises, or Chrome crashes on heavy pages. Each container runs one session at a time unless SE_NODE_MAX_SESSIONS raises it, up to the number of processors, so match pytest-xdist workers to the Grid’s real capacity; extra sessions simply queue. For Safari and real devices, a cloud provider replaces the Grid URL and adds vendor capabilities, usually for credentials, build name and operating system. Keep those capabilities in configuration rather than code, so the same suite runs locally, on your Grid and in the cloud.

Selenium has no reporter, so evidence collection is something you add once and then forget. A pytest hook that runs after each test can grab a screenshot and the page source whenever a test fails, using the driver from the test’s own fixture. Name files after the test so they line up with the JUnit report, and write them to a folder the CI job uploads. Teams that want a richer report add Allure or a similar library on top; the hook below is the minimum that makes a CI failure diagnosable. The same idea works in Java with a TestNG listener or a JUnit 5 extension.

Selenium 4 has shipped many minor releases, and minor does not mean nothing breaks. Deprecated APIs are removed after a warning period: Python lost find_element_by_* in 4.3, the constructor arguments that belong in Options or Service objects in 4.10, and the headless option property in 4.13. Selenium 4.51 removed Guava from the Java bindings, so ExpectedCondition no longer implements Guava’s Function interface and any code that borrowed Guava through Selenium needs its own dependency. Treat upgrades as a small task: read the release post, run the suite with deprecation warnings visible, and fix what they report before the next removal. Upgrade every few releases rather than letting a gap of a year build up.