consolidating-test-setup

First classify each repeated block by the state it owns, its lifetime, and whether it is an invariant or scenario detail. Then remove it tentatively, run affected suites to find the real contract, and place it in the narrowest owner such as runner configuration, a setup file, or a scoped fixture.

Use vitest setupFiles only for invariants that configuration cannot express, and keep test-specific vi.mock calls inside the test module so hoisting works. For shared implementations, use __mocks__ directories with a local vi.mock, and watch for setup files that import the mock target and cache the module.

Fixtures should own resources that need guaranteed setup and teardown at test or worker scope, while global setup is reserved for run-wide resources. The fixture that creates a resource must release it even when the test fails, and mutable test state stays test-scoped unless broader ownership is proven safe under parallel execution.

No. A shared helper only helps if it owns a policy or lifecycle or removes meaningful reader effort; moving identical lines behind a new name is not an improvement. The workflow recommends subtracting suspected cargo-cult setup first and only centralizing after failures reveal the real contract.

Failures usually come from scope mismatches, such as shared process state leaking between suites, module mocks being cached before tests reprogram them, or cleanup not running on failure. Run the complete relevant suite rather than targeted tests, since shared lifecycle issues often appear only when unrelated suites run together.