Skip to content
CodeKruPro

Automation tool (Selenium) · Python

Grid, headless runs and tool choice

Selenium Grid, headless browsers, limits of Selenium and alternatives.

Learn: Selenium Grid, headless runs and tool choice (Python)7 minute read

Selenium Grid runs browsers on other machines, so a suite can run many tests at the same time and cover browsers and operating systems you do not have. Once tests run on your laptop, the next interview questions are about running them at scale and knowing when Selenium is not the right tool. Senior interviewers like this topic because good answers need judgement, not just API names.

Hub and nodes

The hub receives requests for new browser sessions and sends each to a suitable node. A node is a machine or container with browsers and drivers; more nodes mean more capacity.

Tests in CI ask the Grid hub on port 4444 for a session; the hub routes each request to a node with Chrome, Firefox or Edge.
The hub routes each new session to a node with the right browser.

Grid 4 can run as standalone (hub and node in one process), hub and node, or fully distributed, where the hub's parts run separately. The quickest start is the official Docker image:

docker run -d -p 4444:4444 --shm-size="2g" selenium/standalone-chrome

Docker packages a program with everything it needs into a container, a small isolated environment, so you can start Grid with one command. Grid listens on port 4444 (a port is a number that tells the machine which program should receive the request), and http://localhost:4444/status says whether it is ready. In Docker Compose, depends_on only orders container start-up, so a CI script (CI, continuous integration, means a server runs your tests automatically after each code change) or health check should wait for /status before pytest starts.

Connecting from Python, step by step

from selenium import webdriver

options = webdriver.ChromeOptions()
driver = webdriver.Remote(command_executor="http://grid-host:4444", options=options)
  1. Create the browser options as for a local run.
  2. Create webdriver.Remote with the Grid address and the options.
  3. Use the driver exactly as before; the API is the same.

The old desired_capabilities argument is gone and raises TypeError. In a pytest framework, the driver fixture reads a --grid-url option and returns webdriver.Remote(...) when it is set, otherwise a local browser. Uploads work on Grid without extra code, because webdriver.Remote uses a LocalFileDetector by default. Downloads need options.enable_downloads = True, then get_downloadable_files() and download_file().

Headless browsers

Headless means no visible window. Add options.add_argument("--headless=new"); it is normal in CI and containers. The default headless window is small, so set --window-size=1920,1080 or call driver.set_window_size. Screenshots still work, so failure evidence is not lost. Operating system automation tools do not work. Make headless a command-line option rather than hard-coding it, so you can watch the browser when debugging.

What Selenium cannot do

Selenium drives web pages. Native mobile apps need Appium. CAPTCHA and SMS OTP (a one-time password sent by text message) exist to stop automation; ask for a test-environment switch, provider test keys, a fixed test OTP or a test inbox API instead of trying to beat them. There is no built-in visual comparison: Selenium takes screenshots, and a separate library or service compares them with approved images.

Selenium, Playwright or Cypress?

Selenium implements the W3C WebDriver standard, with many languages, drivers from the browser makers, and Grid and cloud providers; waits and reports are your job. Playwright waits automatically before actions and has network mocking (faking server answers), tracing (a recording of each test step) and parallel workers built in, with Python, Java, JavaScript and .NET clients. Cypress runs inside the browser with fast feedback, supports JavaScript and TypeScript only, and makes multiple tabs awkward.

How to answer in an interview

Explain hub and node in two sentences, show the webdriver.Remote line, and say when Grid pays off: a slow suite, parallel CI runs or several browsers. For tool choice, decide by team language, browser coverage, the existing suite and CI. Saying that a working suite often gains more from better waits, fixtures and test data than from a rewrite shows practical judgement.

Common mistakes

  • Passing desired_capabilities from an old tutorial.
  • Starting pytest before the Grid reports ready.
  • Running headless with the default small window.
  • Trying to automate around a CAPTCHA.

Recap

Grid runs browsers remotely: the hub routes sessions to nodes on port 4444. Connect with webdriver.Remote(command_executor=..., options=...). Run headless with a fixed window size, know what Selenium cannot do, and choose tools by what the team needs.

10 questions0/10 solved

StatusQuestionDifficultyAsked in
Not startedSelenium Grid: hub and node, and when you need itMediumAsked in: Accenture, Capgemini, Infosys
Not startedConnect a Python test to Selenium GridEasy-MediumAsked in: Accenture, Capgemini, Infosys
Pro+Starting Selenium GridMediumAsked in: Accenture, Capgemini, Infosys
Pro+Running the browser headless: what changes?Medium
Pro+Which argument starts Chrome headless?Easy
Pro+Can you automate CAPTCHA, OTP or barcodes?MediumAsked in: Accenture, Infosys
Pro+Selenium versus Playwright and CypressMediumAsked in: Capgemini, Infosys
Pro+Mobile automation basics: how Appium worksMediumAsked in: Accenture, TCS, Wipro
Pro+Grid address and readiness checkEasy-MediumAsked in: Accenture, Capgemini, Infosys
Pro+Visual comparison tests and their trapsMedium-Hard
Not startedNot startedIn progressIn progressSolvedSolvedPro+Pro+

The first 2 questions of each topic are free. Pro+ opens every question.

Back to the plan