When to Move an Angular Test Suite to Vitest

Default is not the same as mandate#

For new Angular CLI projects, Vitest is the current default. That is a strong signal about the direction of Angular testing. It is not the same thing as saying every existing Karma/Jasmine suite should be migrated in one branch.

A test runner migration is successful only if the team trusts the result afterward. If the migration makes CI faster but nobody believes the failures or the passes, the project lost signal.

The first slice matters#

What to run first#

The first migration branch should prove configuration, CI behavior, and a small set of test patterns. Do not start by deleting Karma from a large application.

The official migration path includes manual configuration work, optional browser mode, and an experimental schematic for Jasmine-to-Vitest refactoring. That means every generated diff still needs review.

npm install --save-dev vitest jsdom
ng test --no-watch
ng g @schematics/angular:refactor-jasmine-vitest --include=src/app/orders

What would make me wait#

Wait if the suite depends heavily on fakeAsync, flush, browser-only APIs, custom Karma launchers, or global test setup nobody currently understands. Those are not blockers forever, but they are a bad place to start.

The official Vitest migration guide is explicit that Zone.js based helpers such as fakeAsync, flush, and waitForAsync are not supported. New examples in this series should prefer native async, observable assertions, or Vitest timers unless they are clearly labeled as Karma/Jasmine code.

The right proposal is not 'move all tests to Vitest'. It is 'move this slice, compare CI time and failure quality, document unsupported patterns, then decide the next slice'.