testing-strategy

Structure unit tests by colocating *.test.ts files next to source code, and run integration tests using a separate vitest.integration.config.ts file. This separation isolates fast, deterministic unit tests from slower integration tests that require database fixtures and lifecycle management.

The best mocking strategy for Vitest is to mock I/O boundaries with vi.mock and fake timers while avoiding over-mocking internal logic. This maintains determinism and prevents flaky tests caused by race conditions, time dependencies, and shared state.

Set up a test database for Vitest integration tests by defining fixtures in tests/integration/setup.ts and executing tests serially. Truncate data between runs to manage the test lifecycle, ensuring a clean database state and preventing shared resource conflicts.

Configure coverage thresholds directly within the vitest config file to enforce quality metrics for your TypeScript project. Setting explicit limits ensures meaningful coverage across unit and integration suites, preventing superficial tests from passing continuous integration checks.

Flaky Vitest tests are usually caused by race conditions, time dependencies, shared state, or randomization. Fix them by applying a mitigation checklist to isolate shared state, apply fake timers, remove time dependencies, and ensure deterministic test execution.

Yes, Vitest supports separate configurations by using distinct files like vitest.integration.config.ts for integration tests. This allows different lifecycle setups, coverage thresholds, and serial execution rules for shared resources compared to standard unit tests.