Docker & Selenium Grid: Reproducible Test Environments

The idea, in one line

A Docker image bundles your Python version, browser, and dependencies together, so your laptop and the CI runner run the exact same environment.

The Dockerfile, line by line

• FROM — picks a base image to build on.
• WORKDIR — sets the working directory inside the image.
• COPY — brings files in. Copy requirements.txt first, before the rest, so Docker caches the install step and rebuilds fast.
• RUN — runs a build-time command, like installing dependencies.
• ENV — sets an environment variable.
• CMD — the default command when the container starts.

# Dockerfile -- a reproducible test image
FROM python:3.12-slim

WORKDIR /app

# Copy deps first so this layer is cached across rebuilds
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

# Point tests at a Grid instead of a local browser
ENV GRID_URL=http://selenium-hub:4444/wd/hub

# Default command when the container runs
CMD ["pytest", "-n", "auto", "tests/"]

Read it top to bottom: start from slim Python, install the dependencies once (cached), copy the code, and run the tests. Copying requirements.txt before the rest is the trick — if only your test code changed, Docker reuses the cached install instead of reinstalling everything.

Advanced — let the browser live somewhere else

For UI tests you rarely install browsers by hand. Instead you point a RemoteWebDriver at Selenium Grid. Grid takes your commands and routes them to browser instances running elsewhere, so you can run many browsers and versions in parallel across machines. Its parts (Router, Distributor, Nodes) accept a session and hand it to a free browser. Cloud grids like BrowserStack, Sauce Labs, and LambdaTest offer the same thing as a hosted service.

Grounded in the official Dockerfile reference (docs.docker.com) and the Selenium Grid docs