Copyright © 2025 ScriptNG
Designed by ScriptNG
Docker For Test Automation
Sick of messy Selenium setups? Docker it like a pro—fast, clean, done.
🐳 Docker for Testers: Why I Wish I Knew This Sooner
Docker for Testers isn’t just a fancy tech trend—it’s your new best friend if you’re tired of the “It works on my machine” circus. I’ve been in rooms where test environments collapsed minutes before a demo. Selenium Grid broke, browsers misbehaved, and we testers got blamed. Sound familiar?
Now imagine spinning up a clean, fully functional Selenium Grid in literally 10 minutes—on any machine, with zero setup drama. That’s what Docker brings to the table. And once you get the hang of it, you’ll wonder how you ever lived without it.
💥 Why You (Desperately) Need Docker as a Tester
If you’re still running Selenium tests on your local Chrome like it’s 2013… stop. Just stop.
Docker lets you:
Test on any browser/version without installing anything
Spin up isolated test environments like magic
Avoid the “It works on my machine” crap
Wait—I almost forgot. Ever seen Jenkins scream in red because your dev used Chrome 122, and you have 117? Docker fixes that too.
😤 The Setup That Made Me Scream (Then Laugh)
I once spent 3 hours installing Selenium Grid manually for a demo. XML configs. Port conflicts. Firefox throwing tantrums. Felt like assembling IKEA furniture blindfolded.
Then Docker walked in like:
“Chill, I got this.”
Now I spin it up in under 10 minutes, coffee still hot.
⚙️ 🚧 Pre-Reqs – You Need These First
This setup works on Mac, Linux, or Windows. Just install:
(Optional) VS Code with Docker extension
Basic command line skills (copy-paste counts)
🛠️ Let’s Build a Selenium Grid in 10 Mins
✅ Step 1: Docker Compose File
Create a file called docker-compose.yml and paste this in:
version: "3"
services:
selenium-hub:
image: selenium/hub:4.21.0
container_name: selenium-hub
ports:
- "4442:4442"
- "4443:4443"
- "4444:4444"
chrome:
image: selenium/node-chrome:4.21.0
shm_size: 2gb
depends_on:
- selenium-hub
environment:
- SE_EVENT_BUS_HOST=selenium-hub
- SE_EVENT_BUS_PUBLISH_PORT=4442
- SE_EVENT_BUS_SUBSCRIBE_PORT=4443
firefox:
image: selenium/node-firefox:4.21.0
shm_size: 2gb
depends_on:
- selenium-hub
environment:
- SE_EVENT_BUS_HOST=selenium-hub
- SE_EVENT_BUS_PUBLISH_PORT=4442
- SE_EVENT_BUS_SUBSCRIBE_PORT=4443
🔥 Step 2: Fire It Up
Open terminal, go to the folder with your YAML file, and run:
docker-compose up -d
Boom. No drivers. No config files. Just boom.
👀 Step 3: Validate It’s Alive
Go to:
http://localhost:4444/ui
You’ll see a slick Selenium Grid UI showing Chrome and Firefox nodes. Clicking stuff there? It actually feels good.
☕ Real Story: That Time I Deployed Grid in PROD by Mistake
Yup. Misconfigured my Docker network. Ended up hitting PROD APIs with my test scripts running on Grid.
Lesson: always, always check your target URL before you run anything. Even if it’s 2AM and Jenkins is nagging you.
⚔️ What Makes a Bad Setup vs. a Great One
| Bad Selenium Grid | Great Selenium Grid |
|---|---|
| Hardcoded paths | Dockerized setup |
| Manual node add | docker-compose magic |
| OS-specific | OS-agnostic |
| Works once | Scalable & repeatable |
| Eats RAM like cake | Controlled resource usage |
🧠 Checklist: Things Testers Forget (And Regret)
Set browser version tags (e.g.,
node-chrome:114.0)Avoid network name clashes
Use shared volumes only if needed
Clean up after yourself (
docker rm -f $(docker ps -aq)if things go south)Use headless mode for CI—ALWAYS
🔍 DOs and DON’Ts
✅ DO:
- Use
docker-composeover manual setup - Pin image versions
- Keep Grid infra in Git repo (like any code)
- Monitor logs (
docker logs -f selenium-hub)
❌ DON’T:
- Mix old Selenium 3 and 4 images
- Run everything on default bridge network
- Forget to expose
4444for your test scripts - Let your infra rot—build a reset script
FAQs
Docker lets you package your environment, tools, and apps into containers. As a tester, that means you can say goodbye to “But it worked on my machine!” excuses. Consistency is king.
Yes! Docker Desktop supports Windows (with WSL 2). Just install Docker Desktop, enable WSL integration, and you’re good to go.
Use a pre-built docker-compose.yml. In about 10 minutes, you can spin up a hub and multiple nodes (Chrome, Firefox). Your setup will look clean, versioned, and portable.
Because maintaining local browser versions is a nightmare. Docker isolates and manages everything. Plus, running parallel tests on multiple browsers? Docker makes that cakewalk.
Navigate to http://localhost:4444/ui after running your docker-compose file. The grid dashboard will show available nodes and browser sessions.
Hub: The central point where test scripts connect.
Nodes: Where the actual browser instances run.
Absolutely. That’s actually where it shines the most. Integrate it with Jenkins, GitHub Actions, or GitLab CI for full test automation on push or PR.
docker-compose down
docker system prune -f
The first stops/removes containers, the second cleans dangling images and networks.
Port conflicts (especially 4444)
Browser node crashes if you mismatch versions
Slow container startup on older machines
Chrome nodes silently failing due to missing memory or bad config
Check the official Selenium Docker GitHub repo. They maintain versioned hub and node images for Chrome, Firefox, Edge.
Yes. Just modify your docker-compose.yml to add more Chrome/Firefox services and assign different container names/ports.
Yes. Tools like Selenoid offer a more lightweight and efficient Docker-based Selenium execution option. Great for resource-constrained machines.
🎯 Final Words (AKA, My Rant)
Docker for testers isn’t “nice to have” anymore. It’s table stakes.
The next time someone says “But it worked on my machine,” throw a Dockerfile at their face.
This setup saved me HOURS and actually made me look smart in front of the devs. That never happens. 😅
Also Don’t forget to check our blogs.
One Response