Parallel Execution vs. --runInBand for Stateful Test Suites

Concurrency Trade-offs in Vitest

Vitest leverages worker processes to execute test files concurrently by default, which significantly reduces total runtime for large suites. However, this parallelization can introduce non-deterministic failures when tests rely on mutable global state or shared file system resources.

The --runInBand flag provides an alternative by forcing tests to run serially in the main process. While this ensures deterministic execution order and eliminates race conditions, it removes the performance benefits of multi-core utilization, potentially increasing CI pipeline duration.

A specific uncertainty exists regarding the isolation of mocks across these different execution modes. When using parallel workers, it is unclear if mocks are strictly isolated per worker or if state can leak across tests assigned to the same process.

• Does --runInBand provide a different level of mock isolation compared to the default parallel worker pool?
• Under what specific constraints should maxWorkers: 1 be preferred over the --runInBand CLI flag for stateful suites?