---
title: "When to Move an Angular Test Suite to Vitest"
description: "Vitest is the Angular CLI default, but migrating an existing suite is still experimental: which specs to pilot first, what fakeAsync breaks, and how to keep CI trustworthy."
deck: "[Vitest is the default test runner since Angular v21](https://angular.dev/guide/testing) (November 2025), but existing Karma/Jasmine suites deserve a migration filter. The [official migration docs](https://angular.dev/guide/testing/migrating-to-vitest) are explicit: 'Migrating an existing project to Vitest is considered experimental.' Doug Parker had [announced Karma deprecation back in April 2023](https://blog.angular.dev/moving-angular-cli-to-jest-and-web-test-runner-ef85ef69ceca); the path has been long."
author: "André Ramos"
url: "https://andreramos.dev/angular/move-angular-test-suite-to-vitest/"
lang: "en"
type: "article"
---

# When to Move an Angular Test Suite to Vitest

> [Vitest is the default test runner since Angular v21](https://angular.dev/guide/testing) (November 2025), but existing Karma/Jasmine suites deserve a migration filter. The [official migration docs](https://angular.dev/guide/testing/migrating-to-vitest) are explicit: 'Migrating an existing project to Vitest is considered experimental.' Doug Parker had [announced Karma deprecation back in April 2023](https://blog.angular.dev/moving-angular-cli-to-jest-and-web-test-runner-ef85ef69ceca); the path has been long.

## 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

| Candidate | Good first slice? | Why |
|---|---|---|
| Pure pipes | Yes | Low DOM dependency and easy assertion parity. |
| Services without browser globals | Yes | Fast feedback with simple setup. |
| Validation helpers | Yes | Useful for forms without UI complexity. |
| Small components | Maybe | Good if they avoid overlays, animations, and complex timers. |
| Overlay, canvas, drag/drop, browser-heavy specs | Later | They test the hardest migration path first. |

## 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.

*Small Vitest pilot commands*

```bash
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'.

## Reusable artifact: Vitest pilot acceptance criteria

- One small slice migrated and reviewed.
- CI runtime compared before and after.
- Known unsupported patterns documented, especially Zone.js testing helpers.
- Browser-mode need decided explicitly.
- Karma kept until the team trusts the replacement path.

## Sources checked

- https://angular.dev/guide/testing
- https://angular.dev/guide/testing/migrating-to-vitest
- https://angular.dev/api/schematics/refactor-jasmine-vitest
- https://vitest.dev/guide
- https://blog.angular.dev/moving-angular-cli-to-jest-and-web-test-runner-ef85ef69ceca
- https://blog.angular.dev/announcing-angular-v20-b5c9c06cf301
- https://blog.angular.dev/announcing-angular-v21-57946c34f14b
- https://angular.dev/roadmap

## Related

- [Component Testing in Angular with Vitest: TestBed, jsdom, and Browser Mode](https://andreramos.dev/angular/vitest-component-testing-angular/)
- [Mocking Services and HttpClient in Angular Vitest: vi.fn, Spies, and DI](https://andreramos.dev/angular/mocking-angular-services-vitest/)
- [Karma to Vitest in Angular: The Config That Actually Runs](https://andreramos.dev/angular/karma-to-vitest-angular-config/)