🧪 QA: Selenium Grid

QA: Selenium Grid: Docker turns your test environment into a disposable paper cup instead of a glass you have to wash and reuse. Need a fresh browser?

Docker turns your test environment into a disposable paper cup instead of a glass you have to wash and reuse. Need a fresh browser? One command spins up Chrome. Need a clean database? One command gives you a brand-new PostgreSQL, used once and thrown away. So why not just reset the existing test database between runs instead of recreating a whole container? Because a 'reset' script only clears the rows YOU know about — leftover indexes, schema drift, or a stray temp table from a previous failed test silently survive and contaminate the next run. It's the same trap as reusing a static Java test fixture across @Test methods without re-initializing it: state leaks invisibly. The QA payoff is concrete: a 'works on my machine' flaky test almost always traces back to a CI agent whose installed Chrome version or DB schema quietly drifted from yours — disposable containers remove that variable entirely.

Selenium Grid with Docker Compose

Full Selenium Grid — Hub + Chrome + Firefox

Micro Lab: Compose service ordering

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

Step by Step: Compose service ordering

Define network/volume

Identify shared network and volume needs

Define dependencies such as db/cache

Prove readiness with healthcheck or retry

Connect the app service with the correct hostname

Run the test runner and report volume step

Arrange the dependency startup order for Selenium Grid with Compose.

selenium-hub comes up first (no dependencies)