Browser tests fail for reasons that have nothing to do with the app: a different browser version, a missing driver, or a machine that's slightly different from yours. Docker removes that noise, because the browser and its driver come packaged in one image that behaves the same everywhere.
Learning Objectives
- Start a Selenium browser in a container with one command.
- Point an automated test at that browser.
- Explain how containers support parallel runs and CI pipelines.
Step by Step: Run a Browser in a Container
- Port 4444 is the Selenium Grid endpoint your test connects to.
- Port 7900 gives a browser view over VNC, so you can watch the test run.
- --shm-size=2g gives Chrome enough shared memory. Without it, the browser can crash on heavier pages.
- Point your test's remote driver URL at http://localhost:4444 and run it as usual.
Start the Browser
selenium/standalone-chrome
Point the Test at It
http://localhost:4444
Run the Test
the browser runs inside the container
Stop and Clean Up
docker stop, then docker rm
docker run -d -p 4444:4444 -p 7900:7900 --shm-size="2g" selenium/standalone-chrome:latest
Parallel Runs and CI
Each container is a separate browser, so you can start several and split your tests across them. In a CI pipeline, the same container definition runs on every build, which removes most "works on my machine" failures.
| Benefit | Why it helps |
|---|---|
| Same browser everywhere | The version and driver match on your laptop and in CI |
| Easy parallel runs | Start more containers and split the test suite across them |
| Clean state each run | Remove the container and start fresh, with no leftover cookies or files |
| Fast setup | One command replaces installing a browser and its driver by hand |
Advantages and Disadvantages
- + Identical environment on every machine and in CI.
- + Parallel test runs with little extra setup.
- + No manual browser or driver installation.
- − Containers need enough memory and shared memory, or browsers crash.
- − Watching a headless run requires the VNC port or extra setup.
- − The first pull of a large image takes time.
Common Mistakes
Leaving the default shared memory size
Chrome can crash inside a container with too little shared memory. Set --shm-size as shown above.
Using the wrong port in the test
The test must connect to the mapped host port, such as 4444. The container's internal port is not reachable from your test directly.
Forgetting to stop containers
Old browser containers keep using memory and ports. Stop and remove them after each run.
Using :latest for a repeatable test suite
latest can change between runs. Pin a version tag when you need the same browser version every time.
Interview Questions
Why run Selenium tests in Docker?
To get the same browser and driver on every machine and in CI, which reduces environment-related failures and makes parallel runs easy.
Why does Chrome crash in a container sometimes?
Often the shared memory size is too small. Increasing it with --shm-size usually fixes it.
Summary
Docker gives browser tests a repeatable environment. Start the Selenium image, point your tests at port 4444, pin the version, and clean up after each run.