Parallelization / sharding
Split one slow test suite into separate slices and run them at the same time, often on several CI machines.
What it is
Parallelization means running tests at the same time; sharding is the part that divides the suite into non-overlapping slices so each worker gets a different slice. Four shards might each run roughly a quarter of the files on four CI machines, then combine their results into one report. Playwright exposes this directly as --shard=1/4 through --shard=4/4.
Reach for it when the suite is reliable but its wall-clock time is holding up every pull request. Split by measured duration rather than file count when possible: ten tiny unit-test files are not equal to one twenty-minute browser file. Keep each shard independently runnable and make the CI matrix fail if any slice fails.
Gotcha: parallel workers reveal shared-state bugs. Two shards that use the same database, port, account, or output directory can overwrite each other and turn a fast suite into a flaky one. Give each worker unique resources, and merge reports only after every shard has finished.
Ask AI for it
Shard this Playwright suite across four GitHub Actions matrix jobs. Run each job with npx playwright test --shard=<shard>/4 for shard values 1 through 4, give every shard a unique database name and artifact directory, and use Playwright's blob reporter so a final job can run playwright merge-reports. Balance shards from recorded test durations instead of file counts, preserve each job's exit status, and fail the workflow if any shard fails.