⚡ Parallel · Cross-Browser · CI/CD

Parallel · Cross-Browser · CI/CD: Think of parallel testing as a supermarket opening more checkout lanes.

Think of parallel testing as a supermarket opening more checkout lanes. Selenium Grid is the version where each new lane needs its own till, its own card reader and a manager keeping every terminal on the same software version — opening a lane is a project. Playwright is the version where the lanes are already built and you simply say how many to staff. But why does simply adding lanes not automatically make the queue move faster? Because if all the cashiers still share one till drawer, they end up waiting on each other — and that is precisely the condition Playwright removes by giving every worker its own isolated browser context. Concretely, Playwright's parallel test system is the browser-testing counterpart of Java's java.util.concurrent.ForkJoinPool architecture: it splits work into independent subtasks, each worker runs in its own isolated browser context, and because there is no shared state there are no thread-safety problems either. Didn't Selenium Grid already provide parallel execution? Selenium Grid required significant infrastructure setup to manage a remote server network: Hub + Node configuration, Docker container management, keeping driver versions in sync across all nodes. In Playwright, adding workers: 4 to playwright.config.ts is all it takes — as long as tests are written in an isolated way, parallelism is automatic with no extra infrastructure. Cross-browser testing means applying the same test suite simultaneously to Chromium, Firefox, and WebKit projects; in other frameworks you'd need separate configurations for each browser. The QA reality: if a team enforces a "all tests must pass per PR" policy, 500 tests taking 40 minutes blocks every PR and engineers start bypassing tests rather than waiting; with 8 workers that drops to roughly 5 minutes, and developers wait and merge properly — which turns testing into a real quality gate in team culture.

A test suite that takes 30 minutes gets ignored on every commit; one that takes 3 minutes gets run on every commit. Two mechanisms make this possible: (1) parallel workers — splitting tests across multiple CPU cores, and (2) sharding — splitting tests across multiple CI machines. CI/CD integration is the pipeline that triggers all of this automatically.

The workers setting corresponds to Maven Surefire/Failsafe's forkCount + parallel="methods" setting. test.describe.serial() → JUnit 5's @TestMethodOrder for tests that must run in order. --shard=1/4 → Playwright's built-in equivalent of splitting tests across machines via CI matrix builds (something you had to set up manually with Selenium Grid).

Parallel Execution — Worker Settings

Micro Lab: Playwright — Actions

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.

⏱️ Serial vs Parallel (4 Workers) — the Same 4 Test Files

Each file takes ~8 seconds. Running serially on one worker, the times add up; running in parallel on 4 workers, it only takes as long as the slowest single file.

4 files × 8s, one after another

Paralel — workers: 4

4 files run simultaneously, takes as long as the slowest one

Cross-Browser & Mobile Emulation

What Does devices['Pixel 5'] Actually Simulate in One Line?

devices['Pixel 5'] sets…