What Is Test Sharding?
Test sharding cuts one big test suite into slices and runs each slice on a separate runner in parallel, so a 30-minute suite finishes in a few.
A growing test suite eventually dominates pipeline time. Sharding distributes the tests across N runners so each one runs only 1/N of the work. The slowest shard sets the total, so balancing the shards matters as much as splitting them.
How sharding works
You tell the runner the total shard count and which shard it is - for example --shard=2/4. Each runner executes only the tests assigned to it, and a final step combines the results.
A small example
A matrix over shard: [1, 2, 3, 4] launches four jobs, each running playwright test --shard=${{ matrix.shard }}/4. A 32-minute suite split four ways finishes in roughly 8, plus a short fan-in step to merge reports.
Balancing shards
Splitting by file count is uneven - one slow file can stall a shard. Better tooling splits by historical timing so each shard takes roughly equal wall-clock time, minimizing the slowest shard.
Sharding vs parallel jobs
Parallelism runs different jobs at once; sharding parallelizes one job by partitioning its work. Sharding usually pairs with a matrix that enumerates the shard indexes.
Combining results
Each shard emits its own report. A fan-in step downloads all of them and merges into a single coverage and test report, so reviewers see one combined result rather than four partial ones.
Key takeaways
- Sharding splits a suite into slices that run in parallel on separate runners.
- Balance by historical timing, not file count, to shrink the slowest shard.
- It pairs naturally with a matrix over shard indexes and a fan-in merge.