5.3Parallelization

Test Sharding

Split your test suite across multiple runners. Each runner executes a fraction of the tests, and the total wall-clock time is roughly total_time / number_of_shards.

# Playwright sharding
strategy:
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: npx playwright test --shard=${{ matrix.shard }}/4

# Jest sharding
strategy:
  matrix:
    shard: [1, 2, 3]
steps:
  - run: npx jest --shard=${{ matrix.shard }}/3

# pytest-xdist (automatic parallelization within a single runner)
steps:
  - run: pytest -n auto  # Uses all available CPU cores

Choosing the right number of shards:

• Start with 3-4 shards and measure
• Each shard should take roughly the same time (balanced distribution)
• Too many shards means overhead from setup/teardown dominates
• Too few means each shard is still slow

Matrix Strategy for Cross-Cutting Concerns

Combine sharding with other dimensions:

strategy:
  fail-fast: false
  matrix:
    browser: [chromium, firefox]
    shard: [1, 2, 3]
# Creates 6 parallel jobs: chromium-1, chromium-2, chromium-3, firefox-1, firefox-2, firefox-3

Parallel Jobs vs Parallel Tests

• Parallel jobs (matrix strategy): Each job runs on a separate runner. Good for isolation and cross-browser testing.
• Parallel tests (within a job): Use multi-core runners and tools like pytest-xdist or Jest workers. Good for CPU-bound unit tests.

For maximum speed, combine both: run 4 shards on 4 runners, and within each shard, run tests on 2 CPU cores.