🎭 QA: Playwright & CI

QA: Playwright & CI: Running Playwright in Docker is shipping the whole laboratory, not just the experiment: the official image freezes the browser binaries, system fonts, and OS

Running Playwright in Docker is shipping the whole laboratory, not just the experiment: the official image freezes the browser binaries, system fonts, and OS libraries at exact versions, so the pixel your test sees in CI is the pixel you saw locally. Why isn't 'npm install' enough — it already pins the Playwright version, doesn't it? Because your test's behavior also depends on what npm does NOT install: system-level Chromium dependencies, font rendering, timezone, and locale — the same reason a Java team pins the exact JDK image in CI instead of trusting 'whatever Java 17 the agent happens to have'. The QA payoff is retiring the most expensive sentence in test automation, 'flaky — passes on rerun': when your CI browser is bit-for-bit identical to your local one, a red test stops being weather and starts being evidence.

Running Playwright Tests in Docker

Playwright tests in Docker Compose

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

What is the startup order for a Compose-based test environment?

Practice: Make the HTML report persist on the host

Each line under volumes follows HOST_PATH:CONTAINER_PATH; test-results is already mounted correctly — apply the same pattern for playwright-report.

One-liner: run Playwright tests in Docker