Vitest vs Jest vs node:test in 2026: Benchmarked on a Real TypeScript Project

A developer benchmarked Vitest 5.1, Jest 30.5 and Node's built-in node:test against an identical 39-file, 183-test TypeScript suite (387 lines of source, 501 lines of tests) on Node.js 24.22.1, timing cold, warm, single-file, watch and coverage runs as medians of 10 shuffled runs. With default settings Jest plus @swc/jest was fastest on full runs at 0.99 s cold and 0.81 s warm, while Vitest's default forks pool was slowest at 1.59 s cold and 1.51 s warm; disabling isolation flipped the ranking, with node --test --test-isolation=none at 0.52 s cold and Vitest --no-isolate at 0.75 s cold, both beating Jest. The author cautions that the shared VM (load average 3-13 on 8 cores) makes absolute times noisy, so the ranking matters more than the decimals.

Cross-posted from my blog. The original, with any updates, lives on fabwaseem.com https://fabwaseem.com/blog/vitest-vs-jest-vs-node-test . I ran the same TypeScript test suite under Vitest 5.1, Jest 30.5 and Node's built-in node:test , and timed cold runs, warm runs, single files, watch mode and coverage. The suite is 39 test files and 183 tests against a small NestJS-style orders service, an HTTP API and an MCP server. The result surprised me: with default settings, Jest with @swc/jest was the fastest full run, and Vitest was the slowest of the three . Change one isolation setting and the order flips. Below are the numbers, the setup for each runner, and the TypeScript and ESM problems I hit along the way. Everything ran on November 3, 2026 on one Linux VM with 8 vCPUs Intel Xeon and 16 GB of RAM, on Node.js 24.22.1: @vitest/coverage-v8 5.1.0 @swc/jest 0.2.39 and @swc/core 1.16.21, and separately with ts-jest 29.4.15 typescript =4.3 <7 , so it doesn't support TypeScript 7.0.2, the current latest on npm. The code under test is real, not generated: money math with cent allocation, slugs, cursor pagination, an LRU cache, a token-bucket rate limiter, retry with backoff, a CSV parser, an event bus, Zod order schemas, a pricing service, an orders service with status transitions, a node:http JSON API, and the MCP server from my MCP testing guide https://fabwaseem.com/blog/test-mcp-server . That's 387 lines of source and 501 lines of tests. The HTTP and MCP tests start real servers on random ports and call them with fetch and the official MCP SDK client. To keep the suite identical, every test file imports describe , it and hooks from t , a one-line shim that each runner maps to its own API, and asserts with node:assert/strict . Fakes are hand-written, so no runner-specific mocking runs inside the benchmark. I compare the mocking APIs separately below. How I measured: a script ran each configuration 10 times in shuffled order. "Cold" means I deleted the runner's caches first jest --clearCache , and node modules/.vite plus node modules/.vitest-cache for Vitest . "Warm" is the next run with caches in place. Times are whole-process wall clock, and I report the median. Every run had to exit 0 with all 183 tests passing. One honest caveat: this VM is shared, and other jobs were running load average between 3 and 13 on 8 cores . Absolute times are noisy, so read the ranking more than the decimals. I ran the main configurations in two separate batches, and Vitest, Jest and node:test each landed within about 0.1 s of their first-batch medians. 39 files, 183 tests, median of 10 runs: | Runner and config | Cold | Warm | |---|---|---| | Vitest 5.1, defaults forks pool, isolated | 1.59 s | 1.51 s | | Vitest, --pool=threads | 1.55 s | 1.42 s | | Vitest, --pool=vmThreads | 0.91 s | 0.91 s | | Vitest, --no-isolate | 0.75 s | 0.68 s | | Vitest, --fsModuleCache | 1.63 s | 1.52 s | | Jest 30.5 + @swc/jest CommonJS output | 0.99 s | 0.81 s | | Jest + @swc/jest , native ESM --experimental-vm-modules | 1.19 s | 1.01 s | | Jest + ts-jest type-checks every file | 4.30 s | 3.13 s | | Jest + ts-jest , isolatedModules: true | 1.44 s | 1.14 s | | node --test process per file | 1.23 s | 1.24 s | | node --test --test-isolation=none | 0.52 s | 0.51 s | The threads, vmThreads and --test-isolation=none rows come from the second batch. In that batch, the Vitest default, Jest + @swc/jest and node --test rows measured 1.52/1.40 s, 0.95/0.80 s and 1.14/1.23 s. What the numbers say: forks pool starts a fresh child process for each test file, and its own summary told me so: "39 workers spawned, ~81ms startup each". node --test also runs each file in its own process. Jest isolates each file in a separate vm context but reuses its 7 worker processes. Turn isolation off and Vitest 0.68 s and node:test 0.51 s both beat Jest. vmThreads is the middle ground for Vitest. vmMemoryLimit and that objects from Node APIs such as fetch 's response.json and structuredClone have a different prototype. That's the same realm problem I hit with Jest below, and this suite only passed under isolatedModules: true it skips the type checker and drops to 1.14 s. Running tsc --noEmit on the whole project separately took about 1.5 s median of 5 , so a separate type-check step is cheaper than type-checking inside Jest. fsModuleCache stable, but on a project this small it made no measurable difference. To see how the gap scales, I copied the test tree three more times: 156 files and 732 tests, same source. Median of 7 runs: | Runner and config | Cold | Warm | |---|---|---| | Vitest, defaults | 5.15 s | 5.03 s | | Vitest, --pool=vmThreads | 2.29 s | 1.99 s | | Vitest, --no-isolate | 1.32 s | 1.08 s | | Jest + @swc/jest | 1.75 s | 1.52 s | | node --test | 4.32 s | 4.26 s | | node --test --test-isolation=none | 1.08 s | 1.10 s | The per-file process cost grows with the file count. Isolated Vitest went from 1.5 s to 5.0 s, while Jest went from 0.8 s to 1.5 s. Without isolation, Vitest and node:test stay around one second. On a busy machine, process startup is exactly the thing that gets slower, so your numbers on a quiet laptop may be closer together, but the direction should hold. Running only test/orders/service.create.test.ts 4 tests , warm, median of 7: | Runner | Time | |---|---| | node --test | 0.18 s | | Jest + @swc/jest | 0.39 s | | Vitest | 0.40 s | | Jest + ts-jest | 1.40 s | Node has nothing to boot except itself. Vitest and Jest each spend about 0.2 s more starting their runner. I started each runner in watch mode, waited for the first run, then edited a source file and timed the rerun median of 5 . money.ts is imported by 3 test files. events.ts is imported by the shared test fixtures, so 18 files depend on it. | Watch command | Edit money.ts | Edit events.ts | |---|---|---| | vitest --watch | 0.23 s, 3 files | 0.97 s, 18 files | | jest --watch needs git | 0.25 s, 3 files | 0.52 s, 18 files | | jest --watchAll | 0.66 s, all 39 files | 0.61 s, all 39 files | | node --test --watch | 0.31 s, 3 files | 0.94 s, 18 files | All three rerun only the affected test files. Vitest follows the module graph, and node:test did the same in my test. Jest's --watch uses git to find changed files, and outside a git repo it refuses to start "--watch is not supported without git/hg, please use --watchAll" . Vitest's interactive watch UI is the nicest of the three filter by name, rerun failed tests, the optional browser UI , but on raw rerun speed they're close. Full suite with coverage on, median of 5 runs after one warm-up: | Runner | Time | Lines reported | |---|---|---| | Vitest, @vitest/coverage-v8 | 1.99 s | 97.38% | | Jest + @swc/jest , default Babel/Istanbul | 0.99 s | 97.81% | | Jest + @swc/jest , --coverageProvider=v8 | 1.66 s | 98.44% | | node --test --experimental-test-coverage | 1.36 s | 100% lines, 95.79% branches | Coverage added about 0.5 s to Vitest and less to Jest with Istanbul. The percentages aren't comparable between tools, because each counts lines, statements and branches differently. Node said 100% of lines while the others found a few uncovered lines in the same code. Pick one tool for your coverage threshold and stay with it. Node's coverage is still behind the --experimental-test-coverage flag on Node 24. js // vitest.config.ts import { defineConfig } from "vitest/config"; export default defineConfig { test: { include: "test/ / .test.ts" , coverage: { provider: "v8", include: "src/ " }, // isolate: false, // 0.68 s instead of 1.51 s, if your tests don't leak state // pool: "vmThreads", // keeps isolation, 0.91 s here }, } ; That's all it needed. ESM, TypeScript, .ts extensions in imports, top-level await and import.meta all worked without extra config. The exception is decorators: a class with a legacy decorator and a constructor parameter property failed with "SyntaxError: Invalid or unexpected token" under my bare config, even with experimentalDecorators in tsconfig.json . Adding unplugin-swc 2.0.0 to the plugins, with experimentalDecorators and emitDecoratorMetadata in tsconfig, fixed it. If you're on NestJS 12, the Vitest config that nest new generates already handles this. I covered that in my NestJS 12 migration guide https://fabwaseem.com/blog/nestjs-12 . // jest.config.cjs / @type {import 'jest' .Config} / module.exports = { testEnvironment: "node", testMatch: "<rootDir /test/ / .test.ts" , transform: { "^.+\\.ts$": "@swc/jest" }, }; This works if SWC compiles your ESM TypeScript to CommonJS, which is what happens when you don't list .ts in extensionsToTreatAsEsm . It broke in three places: import.meta . if import.meta.url === ... block with a top-level await to start the server when run directly. As CommonJS, Jest failed to parse it: "await is only valid in async functions and the top level bodies of modules". I moved the entry point to its own main.ts , which is cleaner anyway, and used the same code for all three runners. node:assert . Object.prototype . Objects created by Node's globals, like Response.json from assert.deepStrictEqual checks prototypes, so it failed with "Compared values have no visual difference". Jest's own expect .toEqual and toStrictEqual passed on the same objects. Vitest's default pool and node:test didn't have the problem. I changed those tests to JSON.parse await r.text for all runners. jest.mock hoisting. jest.mock call wasn't hoisted when jest was imported from @jest/globals . The real module ran, and my "must not send email" guard threw. Using the global For native ESM, add extensionsToTreatAsEsm: ".ts" , tell SWC to keep ES modules, and start Node with --experimental-vm-modules . On Node 24.22, Jest 30.5 still printed "VM Modules is an experimental feature" for every worker. In this mode, module mocks use jest.unstable mockModule followed by a dynamic import . // jest.esm.config.cjs, run with NODE OPTIONS=--experimental-vm-modules module.exports = { testEnvironment: "node", testMatch: "<rootDir /test/ / .test.ts" , extensionsToTreatAsEsm: ".ts" , transform: { "^.+\\.ts$": "@swc/jest", { module: { type: "es6" } } }, }; ts-jest uses the TypeScript compiler, so it type-checks your tests, which explains the 3.1 s run. It also brings tsconfig friction. My project tsconfig uses "module": "nodenext" and verbatimModuleSyntax in a "type": "module" package, and ts-jest's CommonJS mode failed every file with TS1295: "ECMAScript imports and exports cannot be written in a CommonJS file under 'verbatimModuleSyntax'". I needed a separate tsconfig.jest.json with "module": "commonjs" , verbatimModuleSyntax: false , and a paths entry for the t import Node-style imports aren't resolved with node10 resolution . You also can't move to TypeScript 7 with ts-jest yet, because of the <7 peer range. { "scripts": { "test": "node --test \"test/ / .test.ts\"", "test:watch": "node --test --watch \"test/ / .test.ts\"", "test:cov": "node --test --experimental-test-coverage --test-coverage-include=\"src/ \" \"test/ / .test.ts\"" } } No dependencies and no config. Node 24 strips types by default, and the test runner finds .ts files from the glob. The price is that your TypeScript has to be erasable: Node removes types but doesn't compile anything. I checked each case on Node 24.22.1: | Syntax | node file.ts | --experimental-transform-types | |---|---|---| | enum Status { ... } | ERR UNSUPPORTED TYPESCRIPT SYNTAX | works | | constructor private readonly repo: Repo | ERR UNSUPPORTED TYPESCRIPT SYNTAX | works | | @Injectable decorator | ERR UNSUPPORTED TYPESCRIPT SYNTAX | SyntaxError | So a NestJS codebase full of decorators and parameter properties can't run under plain node --test . My orders service is written NestJS-style, with constructor injection, but it assigns dependencies to private fields by hand instead of using parameter properties. That makes it erasable, and "erasableSyntaxOnly": true in tsconfig keeps it that way. You also need .ts extensions in relative imports allowImportingTsExtensions plus noEmit for tsc and import type for type-only imports verbatimModuleSyntax . The same two jobs in each runner: replace an ES module that sends email, and fake a 60-second timer. All three files below passed. js // Vitest: vi.mock is hoisted above the imports import { vi, it, expect } from "vitest"; import { sendReceipt } from "./receipts.ts"; import { sendEmail } from "./mailer.ts"; vi.mock "./mailer.ts", = { sendEmail: vi.fn async = { id: "msg 1" } } ; it "mocks an ES module", async = { expect await sendReceipt "a@b.co", 7 .toBe "msg 1" ; expect sendEmail .toHaveBeenCalledWith "a@b.co", "Receipt for order 7" ; } ; // timers: vi.useFakeTimers ; vi.advanceTimersByTime 60 000 ; // Jest CommonJS output : use the global jest object so jest.mock gets hoisted import { sendReceipt } from "./receipts.ts"; import { sendEmail } from "./mailer.ts"; jest.mock "./mailer.ts", = { sendEmail: jest.fn async = { id: "msg 1" } } ; // timers: jest.useFakeTimers ; jest.advanceTimersByTime 60 000 ; python // node:test: needs --experimental-test-module-mocks, then a dynamic import import { mock, it } from "node:test"; import assert from "node:assert/strict"; const sendEmail = mock.fn async to: string, subject: string = { id: "msg 1" } ; mock.module "./mailer.ts", { exports: { sendEmail } } ; const { sendReceipt } = await import "./receipts.ts" ; it "mocks an ES module", async = { assert.equal await sendReceipt "a@b.co", 7 , "msg 1" ; assert.deepEqual sendEmail.mock.calls 0 .arguments, "a@b.co", "Receipt for order 7" ; } ; // timers: mock.timers.enable { apis: "setTimeout" } ; mock.timers.tick 60 000 ; Vitest has the smoothest module mocking for ESM. Jest's is fine in CommonJS but needs unstable mockModule and dynamic imports in ESM. Node's mock.module works, but it's experimental: without the flag, mock.module is not a function. Node 24 also prints a deprecation warning if you use the older namedExports option instead of exports . Node's mock.fn , mock.method and mock.timers need no flag and covered everything else I needed. For most service code, constructor injection with hand-written fakes, like this suite uses, avoids module mocking altogether. Pick Vitest for a new TypeScript or ESM project, a Vite or React frontend, or a NestJS 12 app. It needed the least configuration, handled ESM and top-level await without flags, and has the best mocking and watch experience. Its default per-file process isolation is the slowest option at scale, so try pool: "vmThreads" or isolate: false once your suite is stable. Those settings made it the fastest or close to it in my runs. Keep Jest if you have a large, working Jest suite, especially CommonJS. With @swc/jest it was the fastest default configuration here, and moving to Vitest is mostly an API rename jest.fn to vi.fn that buys you little speed unless you also change isolation. Swap ts-jest for @swc/jest and run tsc --noEmit separately: that alone took this suite from 3.13 s to 0.81 s. Pick node:test for libraries, CLIs and backend code written in erasable TypeScript, where zero dependencies matters. It had the fastest single-file runs 0.18 s and the fastest full run without isolation 0.51 s . You give up a rich expect , snapshot ergonomics and stable module mocking, and decorator-heavy code won't run. If you're comparing runtimes too, I measured Bun against Node https://fabwaseem.com/blog/bun-vs-node separately, and I covered what changes in TypeScript 7 https://fabwaseem.com/blog/typescript-7 for build tooling. Not with default settings in my test. On a 39-file TypeScript suite, Jest 30.5 with @swc/jest took 0.81 s warm and Vitest 5.1 took 1.51 s, because Vitest's default forks pool starts a process per test file. With isolate: false Vitest took 0.68 s, and with pool: vmThreads 0.91 s. At 156 files the default gap grew to 1.52 s for Jest against 5.03 s for Vitest. Yes, on Node 24 type stripping is on by default and node --test picks up .ts files from a glob. It only removes types, so enums, constructor parameter properties and decorators fail with ERR UNSUPPORTED TYPESCRIPT SYNTAX. You also need .ts extensions in relative imports and import type for type-only imports. Use @swc/jest and run tsc --noEmit as a separate step. In my runs ts-jest took 3.13 s warm because it type-checks every file, against 0.81 s for @swc/jest, while tsc on the whole project took about 1.5 s. ts-jest 29.4.15 also declares typescript below 7, so it doesn't support TypeScript 7 yet. Yes, but still behind Node's --experimental-vm-modules flag. Jest 30.5 on Node 24.22 ran my suite as native ESM in 1.01 s warm, but printed an experimental warning for every worker, and module mocks need jest.unstable mockModule plus a dynamic import. Compiling to CommonJS with @swc/jest avoids the flag but breaks top-level await and import.meta. They were close. After editing a file imported by 3 test files, Vitest reran in 0.23 s, jest --watch in 0.25 s and node --test --watch in 0.31 s, and all three reran only the affected files. jest --watch needs a git repository; jest --watchAll reruns every file. Originally published on fabwaseem.com https://fabwaseem.com/blog/vitest-vs-jest-vs-node-test .