Are You Still Installing External Test Runners When Node.js Has One Built-In?

I used to spend more time configuring my test runner than actually writing tests. Every time I started a tiny microservice, I’d reflexively reach for Jest, only to find myself twenty minutes deep in a StackOverflow thread about why import statements were blowing up or why ts-jest was suddenly incompatible with my Node version. It was a tax I thought I had to pay. But then Node.js 18 and 20 stabilized the node:test module, and suddenly, my package.json felt about ten pounds lighter.

The "Zero Config" Dream is Finally Real

Let's be honest: Jest is a beast. It’s powerful, but it’s also a massive dependency tree that brings its own mini-operating system into your node_modules. If you're building a modern Node.js app, especially one using ES Modules (ESM), you don't actually need that bloat anymore.

The built-in node:test module is fast. Like, *scary* fast. Because it doesn't have to shim the entire universe or provide a custom VM layer to run your code, it just... runs.

Here is what a basic test looks like now:

import { test, describe } from 'node:test';
import assert from 'node:assert';

describe('The Logic Engine', () => {
  test('it adds numbers without an existential crisis', () => {
    const sum = 1 + 1;
    assert.strictEqual(sum, 2);
  });

  test('async works out of the box', async () => {
    const data = await Promise.resolve({ status: 'ok' });
    assert.deepStrictEqual(data, { status: 'ok' });
  });
});

To run this, you don't need a jest.config.js. You don't need a special CLI tool. You just run:
node --test

Node will automatically find files ending in .test.js or _test.js and execute them. It’s incredibly satisfying to see a test suite finish in 40ms without a "heap limit exceeded" warning in sight.

Mocking without the magic strings

One of the biggest hurdles for the native runner was mocking. We’ve all been spoiled by jest.fn(). For a while, the native runner didn't have a replacement, which made it a hard sell.

That changed. Node now includes a built-in mocking utility that is surprisingly robust. It’s part of the node:test module, and it handles spies and method overrides without the weird global pollution Jest uses.

import test from 'node:test';
import assert from 'node:assert';

test('spying on a function', (t) => {
  const sayHello = t.mock.fn((name) => `Hello, ${name}!`);
  
  const result = sayHello('Node');
  
  assert.strictEqual(result, 'Hello, Node!');
  assert.strictEqual(sayHello.mock.callCount(), 1);
  assert.deepStrictEqual(sayHello.mock.calls[0].arguments, ['Node']);
});

test('mocking an object method', (t) => {
  const database = {
    save: () => 'Real DB hit!'
  };

  // Temporarily replace 'save'
  t.mock.method(database, 'save', () => 'Mocked result');

  assert.strictEqual(database.save(), 'Mocked result');
  // The mock is automatically restored after the test!
});

The t.mock API is context-aware. If you use the t object passed to your test function, Node automatically cleans up your mocks when the test finishes. No more manual afterEach(() => jest.restoreAllMocks()) boilerplate.

Is it perfect? (The "Gotchas")

I'm not going to lie to you and say it’s a 1:1 replacement for everything Vitest or Jest offers. There are some missing pieces that might make you hesitate.

1. Expect syntax: Node's node:assert module uses a functional style (assert.equal(a, b)). If you absolutely crave the chainable .expect(a).toBe(b) syntax, you won't find it here unless you pull in a library like Chai.
2. Snapshots: There is no built-in snapshot testing. If your workflow relies heavily on toMatchSnapshot(), you’ll have to build your own utility or stick with the heavy hitters.
3. UI/Watch Mode: While Node has a --watch flag now, it’s not as interactive as Vitest’s UI. You won't get a pretty dashboard in your browser.

The Coverage Question

For a long time, the lack of a coverage report was a dealbreaker. But Node recently added experimental coverage support. You can now run:

node --test --experimental-test-coverage

It outputs a clean summary in your terminal. It’s not as flashy as an Istanbul HTML report, but for 90% of projects, it’s exactly what you need to see which lines you missed.

Should you switch?

If you are starting a new project today, try the native runner first.

Most of us use external test runners out of habit. We install 50MB of dependencies to check if a function returns an array. It’s overkill. By staying native, you ensure your tests run on every future version of Node without waiting for a third-party maintainer to update their library. You also get a project that starts faster, installs faster, and has fewer security vulnerabilities in your package-lock.json.

If you have a massive legacy Jest suite with 500 snapshots, don't kill yourself trying to migrate. But for that next microservice or that utility library? Just use node:test. Your CI pipeline (and your laptop's fans) will thank you.