Choosing an Angular Test Runner in 2026: Vitest, Jest, or Karma

In Angular 22 (June 2026), Vitest is the stable default test runner in the CLI. Karma still runs for existing suites but is deprecated. The experimental Jest and Web Test Runner builders were dropped once Vitest stabilized; Jest now lives in community tooling like jest-preset-angular. Cypress and Playwright test a different layer, not a Vitest alternative.

For a new project, the decision is already made

Run ng new on Angular 22 and the test command comes wired to Vitest. There is no runner prompt, no choice to agonize over. The CLI made the call, and the official testing guide documents Vitest as the default setup for new projects. For a greenfield app, that is the whole decision: take the default and move on.

The interesting questions start the moment you already have a suite, or you read a 'Cypress vs Vitest' thread and wonder whether you picked wrong. Most of those comparisons ask the wrong thing. The runner stopped being one wide-open contest; it became a small set of decisions that depend entirely on where you are starting from.

What changed: Jest and Web Test Runner left the CLI

Back in 2023, Doug Parker announced the plan to move the Angular CLI off Karma and onto Jest plus Web Test Runner, and for a while the CLI shipped both as experimental builders. Then Vitest arrived, stabilized in v21, and that earlier plan was dropped: the experimental Jest and Web Test Runner builders were deprecated and are no longer part of the v22 testing story.

Jest did not die. It moved out of the CLI and back into community tooling, where jest-preset-angular and the Nx Jest plugin both still work and are actively maintained. So 'Angular removed Jest' is only half true: the CLI removed its own experimental Jest builder, not your jest-preset-angular setup. If that setup is green and fast, v22 does not force your hand.

Where each runner lives nowbash
# Angular 22 CLI: ng test runs Vitest by default
ng test --no-watch

# jest-preset-angular projects keep running Jest directly,
# outside the CLI test builder
npx jest --runInBand

The runners at a glance, Angular 22

ToolWhat it testsStatus in Angular 22
VitestUnit and component logic (Node + jsdom)Default, stable in the CLI
KarmaLegacy unit runner (real browser)Deprecated, still supported for existing suites
JestUnit runnerNo CLI builder; community via jest-preset-angular / Nx
Web Test RunnerExperimental CLI runner (the 2023 plan)Dropped; not in the v22 story
Cypress / PlaywrightComponent-in-browser and e2e (real browser)Complementary to Vitest, a different layer

The decision, by where you start

There is no single best runner. There is the runner that fits your starting point. This is the map I would hand a tech lead asking which way to go.

Where you startIn Angular 22What I'd do
New CLI projectVitest is the defaultTake it. There is no decision to make here.
Karma/Jasmine suite in productionKarma is deprecated but still supportedMigrate in slices, not one branch. Keep Karma running until the team trusts the new signal.
Working jest-preset-angular or Nx JestNo longer a CLI-native builderStay. You lost nothing functional. Move only when you want Vite alignment, not out of fear.
Picking a runner outside the CLIVitest shares the Angular build graphVitest, unless a hard dependency pins you to Jest.
You need real-browser or end-to-end coverageVitest runs in Node with jsdom, not a real browserCypress or Playwright, alongside Vitest, never as a replacement.

Why 'Cypress vs Vitest' is the wrong question

Cypress and Playwright keep showing up in 'versus Vitest' searches, and the framing trips people up. Vitest runs your tests in Node with a jsdom or happy-dom DOM emulation: fast, no browser to boot, ideal for component logic, services, pipes, and signal-driven state. Cypress and Playwright drive a real browser: slower, but they catch what a Node emulation cannot reach, including real layout, native events, cookies, focus, and network failures.

The Vitest documentation itself recommends using them together: Vitest for headless logic, a browser runner for what only a browser can verify. So the honest question stops being 'which one wins' and becomes 'which layer is this bug in?'. If the bug is logic, it goes to Vitest. If it only reproduces in a real browser, that is Cypress or Playwright territory, and Vitest was never going to cover it.

Reusable artifact

Angular test runner decision rule

  • New project: take Vitest. The CLI already decided; do not relitigate it.
  • Existing Karma suite: migrate in slices and keep Karma until the team trusts the new failures and passes.
  • Working jest-preset-angular or Nx Jest: stay. v22 removed the CLI's Jest builder, not your setup.
  • Need real-browser or end-to-end checks: add Cypress or Playwright next to Vitest, never in place of it.
  • Stuck choosing: ask which layer the bug lives in before you name a tool.

FAQ

What is the default test runner in Angular 22?

Vitest. New Angular CLI projects are scaffolded with Vitest, and the official testing guide documents it as the default setup. Karma is still supported for existing projects but is deprecated, and the CLI's earlier experimental Jest and Web Test Runner builders are no longer part of the story.

Is Karma dead in Angular?

Not dead, but deprecated. Karma stopped getting new features after its 2023 deprecation, and Vitest is now the default. The official guide still lists Karma as supported, so an existing Karma suite keeps running and you are not forced to migrate in a single release. Treat the deprecation as direction, not a deadline.

Can I still use Jest with Angular?

Yes, through community tooling. The Angular CLI removed its own experimental Jest builder, but jest-preset-angular and the Nx Jest plugin both still work and are maintained. If your Jest setup is fast and green, Angular 22 does not push you off it; you are simply no longer on a CLI-native path.

Cypress vs Vitest, which one should I choose?

Neither replaces the other. Vitest runs unit and component logic in Node with a jsdom emulation; Cypress and Playwright drive a real browser for what only a browser can verify, like layout, native events, and end-to-end flows. The Vitest docs recommend using them together. Choose by layer: logic goes to Vitest, real-browser behavior goes to Cypress or Playwright.

Should I migrate my Karma suite to Vitest right now?

Only deliberately. Migrating an existing project is labeled experimental in the official docs, and a runner migration only pays off if the team still trusts the results afterward. Migrate a small slice first, compare CI time and failure quality, document what breaks (Zone.js helpers like fakeAsync are not supported), then decide the next slice.

Sources checked

Angular Vitest Migration Kit

Migrating this suite to Vitest?

The Angular Vitest Migration Kit sizes your migration by risk, then packages the config, the fakeAsync cookbook, an AI-agent skill, and a runnable demo. The conversions in this article, done for you.

Verified on Angular 21.2.14 / Vitest 4.1.8. Includes the migration estimator, the PDF guide, copy-paste config, an AI-agent skill, and a runnable demo.

Get the kit · US$15 →

Related

Guide · 6 min

When to Move an Angular Test Suite to Vitest

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.

Read article →

Guide · 7 min

Karma to Vitest in Angular: The Config That Actually Runs

What the Angular v21 Vitest test target actually is (one line), where polyfills and styles come from, the install that drops Karma, and the few options worth adding.

Read article →

Guide · 8 min

Component Testing in Angular with Vitest: TestBed, jsdom, and Browser Mode

How Angular component tests actually behave under Vitest: TestBed is unchanged, the DOM is jsdom (no layout, no real CSS), and the specs that need a real browser are the ones to move to Vitest browser mode.

Read article →