How does Playwright's fullyParallel setting change the way --shard divides a suite?
answer
- Granularity comes from one config flag
- Files are the default atom
- fullyParallel makes tests the atom
- Counts drive the split, not durations
- Serial groups travel as one unit
basics
~20 sIt changes the unit being split. With fullyParallel off, Playwright shards whole spec files, so one file never spans two shards. With it on, individual tests are sharded, so shards get roughly equal test counts.
solid answer
~40 sSharding always divides a list of units, and `fullyParallel` decides what a unit is. Left off, the unit is a **spec file**: every test in one file lands in the same shard, so a file holding 200 payroll checks is indivisible and the shard that receives it carries all 200. Set `fullyParallel: true` and the unit is the **individual test**, so a single file can span several shards and each shard receives roughly the same number of tests. Either way Playwright balances by *count* of units, not by how long they take, because it does not read timing data from earlier runs. Tests bound together by a serial group stay in one shard, since they must run in one worker.
code
typescript · 6 linesimport { defineConfig } from '@playwright/test';
export default defineConfig({
fullyParallel: true,
testDir: './tests/payroll',
});go deeper
Remember that fullyParallel is the switch deciding whether shards are handed whole spec files or individual tests. Without it, every test in one file runs on the same machine.
Explain the two grains and their consequence: files are indivisible by default, so file sizes drive the balance, while fullyParallel makes the test the unit and evens the counts out.
Show that even test counts are not even work, since the split is by count and never by measured duration, and that enabling fullyParallel also demands genuinely independent tests and repeats per-file setup.
Own the tradeoff between even shards and the test-independence rules the suite must then obey, and decide whether duration-aware splitting is worth building outside the runner at all.
## Two different atoms Sharding never splits an atom. `--shard=2/4` takes an ordered list of units, cuts it into four parts and keeps the second. What makes the balance good or bad is what a unit *is*, and in Playwright that is decided by one config flag. - With `fullyParallel` unset or `false`, the unit is a **spec file**. - With `fullyParallel: true`, the unit is an **individual test**. ## File-level splitting By default Playwright runs files in parallel and the tests inside one file in sequence within a single worker. Sharding follows that grain: a file is handed to exactly one shard, whole. For a payroll regression suite this matters as soon as file sizes are uneven. A repository with `payroll-run.spec.ts` holding 200 assertions about a pay cycle and twenty small files holding five tests each gives a four-way split where one shard owns the 200-test file and the other three share the remainder. The counts are lopsided and no flag other than `fullyParallel` changes that, because the file cannot be cut. ## Test-level splitting ```ts import { defineConfig } from '@playwright/test'; export default defineConfig({ fullyParallel: true, }); ``` With `fullyParallel: true`, tests are independent units both for workers and for shards. The big `payroll-run.spec.ts` is dealt out across all four shards, and each shard ends up with roughly a quarter of the tests. The same file may therefore be loaded on all four machines, and each machine runs only its own tests from it. Anything a file did once for all of its tests, such as module-level setup or a `beforeAll`, will now happen in every shard that received one of its tests. ## What Playwright balances on Balancing is by **count of units**, not by measured duration. Playwright does not read timings from a previous run, and there is no built-in facility that records how long each test took and feeds that back into the next split. Two consequences follow: 1. Equal test counts do not mean equal work; a shard holding a handful of long end-to-end journeys can hold more work than a shard holding many fast checks. 2. The split is deterministic and reproducible; the same code and the same total always produce the same slices, which is what lets independent machines agree without talking. ## Side by side | | fullyParallel off | fullyParallel on | |---|---|---| | Unit of sharding | whole spec file | individual test | | Can one file span shards? | no | yes | | Balance quality | follows file sizes | roughly equal test counts | | Per-file setup cost | paid once | paid in each shard that got a test from it | | Balanced by duration? | no | no | ## What stays glued together Tests that must run in order in one worker are not separated by sharding either; a serial group travels as one unit. If a payroll suite chains *create employee, run payroll, verify payslip* as an ordered group, turning `fullyParallel` on does not scatter those three across machines. ## Practical reading - If shards look badly uneven, look at test counts per file first; that is the shape `fullyParallel` controls. - Enabling `fullyParallel` is a real behaviour change, not just a balancing knob: tests in a file now run in parallel with each other and must be independent of one another. - Expect file-level setup to be repeated once per shard when tests from that file are spread out. - Do not expect Playwright to learn from previous runs; the split is arithmetic over the current test list, nothing more.
- A single spec file holds 200 payroll tests and dominates one shard. What changes that without editing the file?Turn on `fullyParallel`. The unit of sharding becomes the individual test, so those 200 tests are dealt across all shards instead of landing on one. The tests must genuinely be independent of each other first, because the same switch also makes them run in parallel inside a single machine.
- Does Playwright use timings from the previous run to make the shards even?No. The split is a deterministic division of the current unit list by count, with no timing feedback and no persisted history. Even shards therefore mean equal numbers of files or tests, not equal amounts of work; any duration-aware splitting has to be built outside Playwright.
Dividing a library by book keeps every chapter of a thick book on one shelf; dividing it by chapter lets that same book spread across all the shelves evenly.
saying these in an interview costs you the question
- Thinks sharding always splits individual tests
- Believes Playwright balances shards by measured duration
- Thinks fullyParallel only affects workers on one machine
- Assumes a spec file can span shards by default
- Confuses the shard total with the worker count
- Expects per-file setup to run once across all shards