{"id":506,"date":"2026-07-26T05:03:45","date_gmt":"2026-07-26T05:03:45","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/node-built-in-test-runner-deleted-jest\/"},"modified":"2026-07-26T05:03:45","modified_gmt":"2026-07-26T05:03:45","slug":"node-built-in-test-runner-deleted-jest","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/node-built-in-test-runner-deleted-jest\/","title":{"rendered":"I deleted Jest for Node’s built-in test runner"},"content":{"rendered":"

Okay, this is going to sound petty, but I deleted Jest from a side project last month mostly because I was tired of its config. Not because it was slow, not because it was broken. I just didn’t want to think about transform<\/code> and moduleNameMapper<\/code> and which Babel plugin I needed this week. I swapped in Node’s built-in test runner to see how far it’d get me, and I haven’t gone back on that project since.<\/p>\n

Short version: if you’re on a recent Node and your tests don’t need a browser, the node test runner that ships with the runtime might already be enough. No install, no config file, no plugin archaeology. Here’s what I found once I actually used it in anger.<\/p>\n

I’ll caveat this up front: I’m not a testing purist, and I don’t think the tool you pick matters as much as the fact that you write the tests at all. But friction is real, and every dependency in a test setup is one more thing that breaks on a Tuesday for reasons unrelated to your code. So a runner with nothing to break got my attention.<\/p>\n

What “built in” actually buys you<\/h2>\n

The thing that clicked for me is that there’s nothing to add. The test runner lives inside Node itself, under the node:test<\/code> module, and it’s been marked stable since Node 20. That means zero dependencies in your package.json<\/code> for the test layer, millisecond-ish startup because there’s no bundler warming up, V8-native coverage, built-in mocking, and a watch mode. The official Node.js test runner docs<\/a> lay out the full surface, and it’s smaller and calmer than I expected.<\/p>\n

The old way, a fairly minimal Jest setup, looked like this before I ripped it out:<\/p>\n

\/\/ package.json \u2014 the Jest era\n{\n  "scripts": { "test": "jest" },\n  "devDependencies": {\n    "jest": "^29.0.0",\n    "ts-jest": "^29.0.0",\n    "@types\/jest": "^29.0.0"\n  },\n  "jest": {\n    "preset": "ts-jest",\n    "testEnvironment": "node",\n    "moduleNameMapper": { "^@\/(.*)$": "<rootDir>\/src\/$1" }\n  }\n}\n<\/code><\/pre>\n
Three dev dependencies and a config block, just to run a function and check its output. The new way is a script and nothing else:<\/p>\n
\/\/ package.json \u2014 the node:test era\n{\n  "scripts": { "test": "node --test" }\n}\n<\/code><\/pre>\n
That’s the whole thing. node --test<\/code> finds your test files, runs them, and reports. I genuinely didn’t believe it the first time.<\/p>\n
Writing an actual test<\/h2>\n
The API will feel familiar if you’ve used more or less any runner in the last decade. You get test<\/code>, you get describe<\/code> and it<\/code>, and assertions come from Node’s own assert<\/code> module. Here’s the before, in Jest:<\/p>\n
\/\/ sum.test.js \u2014 Jest\nconst { sum } = require(".\/sum");\n\ndescribe("sum", () => {\n  it("adds two numbers", () => {\n    expect(sum(2, 3)).toBe(5);\n  });\n});\n<\/code><\/pre>\n
And the after, using only what Node hands you:<\/p>\n
\/\/ sum.test.js \u2014 node:test\nimport { test, describe, it } from "node:test";\nimport assert from "node:assert\/strict";\nimport { sum } from ".\/sum.js";\n\ndescribe("sum", () => {\n  it("adds two numbers", () => {\n    assert.equal(sum(2, 3), 5);\n  });\n});\n<\/code><\/pre>\n
The difference that matters isn’t the assertion style. It’s that the second file imports from node:test<\/code> and node:assert<\/code>, which are already on your machine. Nothing resolved from node_modules<\/code>. If you’ve ever spent an evening debugging why a test runner couldn’t find a module that clearly exists, you’ll understand why this feels like a small weight lifting.<\/p>\n
One habit worth building: import assertions from node:assert\/strict<\/code> rather than plain node:assert<\/code>. The strict variant makes equal<\/code> behave like ===<\/code> instead of the loose ==<\/code>, and I’ve been bitten by the loose version comparing 2<\/code> and \"2\"<\/code> as equal. The full set of matchers lives in the Node.js assert docs<\/a>, and it covers more than you’d guess: deep equality, rejects, throws, the usual suspects. I rarely need more than five of them.<\/p>\n
Mocking without pulling in a library<\/h2>\n
This was the part I assumed I’d miss, and the reason I figured I’d crawl back to Jest. I didn’t. The runner ships with a mock<\/code> object that does spies, method replacement, and timer control, and it cleans up after itself when the test finishes so you’re not leaking mocked state between cases.<\/p>\n
import { test } from "node:test";\nimport assert from "node:assert\/strict";\n\ntest("calls the notifier once", (t) => {\n  const notifier = { send: () => {} };\n  t.mock.method(notifier, "send");\n\n  doTheThing(notifier);\n\n  assert.equal(notifier.send.mock.callCount(), 1);\n});\n<\/code><\/pre>\n
The t.mock.method<\/code> call replaces send<\/code> with a spy for the length of that test and restores it automatically. No beforeEach<\/code> cleanup, no jest.restoreAllMocks()<\/code> you’ll forget to write. There’s a good practical walkthrough of the mocking surface in this Better Stack guide to the Node test runner<\/a> if you want more than the toy example.<\/p>\n
Coverage and TypeScript, the two things I actually checked<\/h2>\n
Coverage used to mean wiring up a separate tool. Now it’s a flag:<\/p>\n
node --test --experimental-test-coverage\n<\/code><\/pre>\n
It uses V8’s native coverage under the hood, so there’s no instrumentation step slowing your suite down. The report it prints is plain, but it’s honest, and for a side project it’s all I need.<\/p>\n
TypeScript surprised me most. On recent Node, type stripping is on by default for erasable TypeScript syntax, which landed around Node 22.18. In practice that means I can point node --test<\/code> at .ts<\/code> files and it runs them without ts-jest, without a build step, without a tsconfig<\/code> fight. There are edge cases, mostly around enums and other non-erasable features, but for the plain “types as annotations” code I write most of the time, it just works.<\/p>\n
Getting it to behave in CI<\/h2>\n
The one place the defaults tripped me up was continuous integration. Run node --test<\/code> in a pipeline and the human-readable output is fine to read, but most CI dashboards want something machine-parseable. The runner has reporters built in for exactly this, so you don’t reach for a plugin:<\/p>\n
# Pretty output locally, TAP for the CI to parse.\nnode --test --test-reporter=spec        # local, readable\nnode --test --test-reporter=tap         # CI, parseable\n<\/code><\/pre>\n
You can even run two reporters at once, sending the pretty version to your terminal and the TAP version to a file the CI picks up. I had this working in about five minutes, which is roughly four minutes and thirty seconds faster than the last time I configured a Jest reporter.<\/p>\n
The other CI nicety: exit codes are sane. A failing test exits non-zero, a passing run exits zero, and there’s no wrapper script translating between formats. My pipeline config for the test step is now a single line, and I keep waiting for the catch. Haven’t found one yet.<\/p>\n
When I still don’t use it<\/h2>\n
I want to be fair, because this isn’t a clean win for every project. If your tests touch the DOM or need a real browser, the built-in runner isn’t your tool, and reaching for something browser-aware is the right call. When a project already leans hard on Vite, I keep using Vitest, since it runs tests through the same transform pipeline as the dev server and that consistency is worth more than shedding a dependency. I got into that tradeoff in my post on Vitest versus Jest<\/a>, and none of that changed.<\/p>\n
The built-in runner shines for backend code, libraries, and CLI tools: the stuff that runs in Node anyway. It pairs especially well with projects already trimming their dependency count, which is the same instinct that pushed me toward alternative runtimes in my year of running Bun in production<\/a>. Fewer moving parts, fewer things to patch.<\/p>\n
If you want to see the kind of small, dependency-light tooling I build around this, some of it lives on my portfolio<\/a>.<\/p>\n
Try this on one file this week<\/h2>\n
Don’t migrate a whole suite. Pick one test file in a Node-only project, rename your imports to pull test<\/code> and assert<\/code> from node:test<\/code> and node:assert\/strict<\/code>, and run it with node --test<\/code>. Give it fifteen minutes. If you’re like me, the thing you’ll notice isn’t speed. It’s the quiet: no config file staring at you, nothing to keep updated, one less corner of the project that can rot. That quiet turned out to be the feature I actually wanted.<\/p>\n","protected":false},"excerpt":{"rendered":"
The node test runner now ships inside the runtime: zero dependencies, built-in mocking, coverage, even TypeScript. Where I dropped Jest for it, and where I didn’t.<\/p>\n","protected":false},"author":2,"featured_media":505,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"The node test runner now ships inside the runtime: zero dependencies, built-in mocking, coverage, even TypeScript. Where I dropped Jest for it, and where I didn't.","rank_math_focus_keyword":"node test runner","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[165,197],"tags":[578,199,576,577,379,201,63],"class_list":["post-506","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-javascript","category-testing","tag-javascript-testing","tag-jest","tag-node-test-runner","tag-node-test","tag-node-js","tag-tooling","tag-typescript"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/506","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=506"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/506\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/505"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=506"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=506"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=506"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}