Safe Test Parallelization

Cut suite time by running in parallel — without tests stepping on each other.

  • ci
  • performance
  • isolation

Problem

The suite is correct but slow, so feedback lags. Naively enabling parallelism makes tests fail intermittently as they fight over shared data and ports.

Solution

Parallelism is safe only when tests are isolated. Give each worker its own data namespace (schema, prefix, or container) and never rely on execution order. Then enable the runner’s parallel mode and shard across CI machines.

Make shared resources per-worker: a unique DB schema or a random port keyed by the worker index removes contention.

Snippets

Namespace shared resources by worker
// Vitest/Jest expose a unique id per worker.
const workerId = process.env.VITEST_WORKER_ID ?? '1';
const schema = `test_${workerId}`;

beforeAll(async () => {
  await db.createSchema(schema);
});
afterAll(async () => {
  await db.dropSchema(schema);
});
Shard across CI machines
# Playwright: split the suite across 4 runners
npx playwright test --shard=1/4

Pitfalls

  • Shared global state (a single test DB, fixed ports) — the classic cause of parallel flakiness.
  • Order-dependent tests that only pass when run sequentially.
  • Over-sharding tiny suites: worker startup overhead can outweigh the savings.

See also

Guide: Designing Reliable E2E Tests →Tool: k6 →