Using Node.js's test runner
Node.js has a flexible and robust built-in test runner. This guide will show you how to set up and use it.
example/
├ …
├ src/
├ app/…
└ sw/…
└ test/
├ globals/
├ …
├ IndexedDb.js
└ ServiceWorkerGlobalScope.js
├ setup.mjs
├ setup.units.mjs
└ setup.ui.mjs
Note: globs require node v21+, and the globs must themselves be wrapped in quotes (without, you'll get different behaviour than expected, wherein it may first appear to be working but isn't).
There are some things you always want, so put them in a base setup file like the following. This file will get imported by other, more bespoke setups.
General setup
import { } from 'node:module';
('some-typescript-loader');
// TypeScript is supported hereafter
// BUT other test/setup.*.mjs files still must be plain JavaScript!
Then for each setup, create a dedicated setup
file (ensuring the base setup.mjs
file is imported within each). There are a number of reasons to isolate the setups, but the most obvious reason is YAGNI + performance: much of what you may be setting up are environment-specific mocks/stubs, which can be quite expensive and will slow down test runs. You want to avoid those costs (literal money you pay to CI, time waiting for tests to finish, etc) when you don't need them.
Each example below was taken from real-world projects; they may not be appropriate/applicable to yours, but each demonstrate general concepts that are broadly applicable.
Dynamically generating test cases
Some times, you may want to dynamically generate test-cases. For instance, you want to test the same thing across a bunch of files. This is possible, albeit slightly arcane. You must use test
(you cannot use describe
) + testContext.test
:
Simple example
import from 'node:assert/strict';
import { } from 'node:test';
import { } from '…';
const = [
{
: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.3',
: 'WIN',
},
// …
];
('Detect OS via user-agent', { : true }, => {
for (const { , } of ) {
.(, () => .((), ));
}
});
Advanced example
import from 'node:assert/strict';
import { } from 'node:test';
import { } from './getWorkspacePJSONs.mjs';
const = ['node.js', 'sliced bread'];
('Check package.jsons', { : true }, async => {
const = await ();
for (const of ) {
// ⚠️ `t.test`, NOT `test`
.(`Ensure fields are properly set: ${.name}`, () => {
.(.keywords, );
});
}
});
Note: Prior to version 23.8.0, the setup is quite different because
testContext.test
was not automatically awaited.
ServiceWorker tests
ServiceWorkerGlobalScope
contains very specific APIs that don't exist in other environments, and some of its APIs are seemingly similar to others (ex fetch
) but have augmented behaviour. You do not want these to spill into unrelated tests.
import { } from 'node:test';
import { } from './globals/ServiceWorkerGlobalScope.js';
import './setup.mjs'; // 💡
();
function () {
. = new ();
}
import from 'node:assert/strict';
import { , , } from 'node:test';
import { } from './onActivate.js';
('ServiceWorker::onActivate()', () => {
const = .;
const = .(async function () {});
const = .(async function () {});
class extends {
constructor(...) {
super('activate', ...);
}
}
before(() => {
. = {
: { , },
};
});
after(() => {
. = ;
});
('should claim all clients', async () => {
await (new ());
.(..(), 1);
.(..(), 1);
});
});
Snapshot tests
These were popularised by Jest; now, many libraries implement such functionality, including Node.js as of v22.3.0. There are several use-cases such as verifying component rendering output and Infrastructure as Code config. The concept is the same regardless of use-case.
There is no specific configuration required except enabling the feature via --experimental-test-snapshots
. But to demonstrate the optional configuration, you would probably add something like the following to one of your existing test config files.
By default, node generates a filename that is incompatible with syntax highlighting detection: .js.snapshot
. The generated file is actually a CJS file, so a more appropriate file name would end with .snapshot.cjs
(or more succinctly .snap.cjs
as below); this will also handle better in ESM projects.
import { , , , } from 'node:path';
import { snapshot } from 'node:test';
snapshot.();
/**
* @param {string} testFilePath '/tmp/foo.test.js'
* @returns {string} '/tmp/foo.test.snap.cjs'
*/
function () {
const = ();
const = (, );
const = ();
return (, `${}.snap.cjs`);
}
The example below demonstrates snapshot testing with testing library for UI components; note the two different ways of accessing assert.snapshot
):
import { , } from 'node:test';
import { } from '@testing-library/dom';
import { } from '@testing-library/react'; // Any framework (ex svelte)
import { } from './SomeComponent.jsx';
('<SomeComponent>', () => {
// For people preferring "fat-arrow" syntax, the following is probably better for consistency
('should render defaults when no props are provided', => {
const = (< />).container.firstChild;
..(());
});
('should consume `foo` when provided', function () {
const = (< ="bar" />).container.firstChild;
this.assert.snapshot(());
// `this` works only when `function` is used (not "fat arrow").
});
});
⚠️
assert.snapshot
comes from the test's context (t
orthis
), notnode:assert
. This is necessary because the test context has access to scope that is impossible fornode:assert
(you would have to manually provide it every timeassert.snapshot
is used, likesnapshot(this, value)
, which would be rather tedious).
Unit tests
Unit tests are the simplest tests and generally require relatively nothing special. The vast majority of your tests will likely be unit tests, so it is important to keep this setup minimal because a small decrease to setup performance will magnify and cascade.
import { } from 'node:module';
import './setup.mjs'; // 💡
('some-plaintext-loader');
// plain-text files like graphql can now be imported:
// import GET_ME from 'get-me.gql'; GET_ME = '
import from 'node:assert/strict';
import { , } from 'node:test';
import { } from './Cat.js';
import { } from './Fish.js';
import { } from './Plastic.js';
('Cat', () => {
('should eat fish', () => {
const = new ();
const = new ();
.(() => .eat());
});
('should NOT eat plastic', () => {
const = new ();
const = new ();
.(() => .eat());
});
});
User Interface tests
UI tests generally require a DOM, and possibly other browser-specific APIs (such as IndexedDb
used below). These tend to be very complicated and expensive to setup.
If you use an API like IndexedDb
but it's very isolated, a global mock like below is perhaps not the way to go. Instead, perhaps move this beforeEach
into the specific test where IndexedDb
will be accessed. Note that if the module accessing IndexedDb
(or whatever) is itself widely accessed, either mock that module (probably the better option), or do keep this here.
import { } from 'node:module';
// ⚠️ Ensure only 1 instance of JSDom is instantiated; multiples will lead to many 🤬
import from 'global-jsdom';
import './setup.units.mjs'; // 💡
import { } from './globals/IndexedDb.js';
('some-css-modules-loader');
(, {
: 'https://test.example.com', // ⚠️ Failing to specify this will likely lead to many 🤬
});
// Example of how to decorate a global.
// JSDOM's `history` does not handle navigation; the following handles most cases.
const = ...(.);
.. = function (, , ) {
(, , );
..();
};
beforeEach();
function () {
.indexedDb = new ();
}
You can have 2 different levels of UI tests: a unit-like (wherein externals & dependencies are mocked) and a more end-to-end (where only externals like IndexedDb are mocked but the rest of the chain is real). The former is generally the purer option, and the latter is generally deferred to a fully end-to-end automated usability test via something like Playwright or Puppeteer. Below is an example of the former.
import { , , , } from 'node:test';
import { } from '@testing-library/dom';
import { } from '@testing-library/react'; // Any framework (ex svelte)
// ⚠️ Note that SomeOtherComponent is NOT a static import;
// this is necessary in order to facilitate mocking its own imports.
('<SomeOtherComponent>', () => {
let ;
let ;
(async () => {
// ⚠️ Sequence matters: the mock must be set up BEFORE its consumer is imported.
// Requires the `--experimental-test-module-mocks` be set.
= .('./calcSomeValue.js', {
: .(),
});
({ } = await import('./SomeOtherComponent.jsx'));
});
('when calcSomeValue fails', () => {
// This you would not want to handle with a snapshot because that would be brittle:
// When inconsequential updates are made to the error message,
// the snapshot test would erroneously fail
// (and the snapshot would need to be updated for no real value).
('should fail gracefully by displaying a pretty error', () => {
.mockImplementation(function () {
return null;
});
(< />);
const = .queryByText('unable');
assert.ok();
});
});
});