Testing & Tooling

Why tooling matters

Writing code is only half the job. Knowing how to test, debug, measure, and configure your Node.js environment turns a working script into a maintainable, production-ready application.

Node 24 (the active LTS) ships a built-in test runner, type stripping for .ts files, a powerful inspector protocol, and perf_hooks for timing — meaning you can do a lot without installing anything.

Node release lines in 2026

Line	Status (Sep 2026)	Use it for
Node 22	Maintenance LTS (until Apr 2027)	Existing production apps — require(esm), type stripping since 22.18
Node 24	Active LTS (LTS since Oct 2025)	New production apps — this course targets it
Node 26	Current (LTS from Oct 2026)	Trying Temporal, Iterator.concat(), Undici 8

Node 18 and 20 are end-of-life. When a lesson says “Node 22+”, the feature exists on every supported line.

What this module covers

Lesson	Topic
Built-in Test Runner	node:test, node:assert, test(), describe/it, node --test
Debugging	node --inspect, Chrome DevTools, breakpoints, console methods
Performance	perf_hooks, performance.now(), PerformanceObserver, avoiding blocking
Ecosystem & Toolchain	TypeScript runners, ESLint/Prettier/Biome, nodemon, env files

The toolchain at a glance

flowchart TB
  subgraph Project["Your Node.js Project"]
    direction TB
    Source["Source code (.ts / .js / .mjs)"]
    Lint["Linter / Formatter"]
    TSR["TypeScript runner"]
    TestRunner["Test runner"]
    Debugger["Debugger"]
    Perf["Performance"]
    Source --> Lint --> TSR --> TestRunner --> Debugger --> Perf
  end
  Lint --> LintTools["ESLint, Prettier, Biome"]
  TSR --> TSRTools["node file.ts (built-in type stripping); tsx for enum etc."]
  TestRunner --> TestTools["node:test (built-in) or Vitest / Jest"]
  Debugger --> DebuggerTools["node --inspect + Chrome DevTools"]
  Perf --> PerfTools["perf_hooks, PerformanceObserver"]

A Node.js project's toolchain: source flows through the linter, TypeScript runner, test runner, debugger, and performance tools

Choosing what to install

Node’s built-ins cover most basic needs. Here is a quick decision guide:

# Zero dependencies — use the built-in runner
node --test src/**/*.test.js

# TypeScript without a build step (Node 22.18+ / 24 — type stripping is on by default)
node src/app.ts

# Run a package.json script without npm (Node 22+)
node --run dev

# Faster HMR + watch mode
npx tsx watch src/app.ts

# Lint + format in one tool (zero config)
npx biome check --apply src/

🟢 Built-in first, then extend

Start with node:test, node --inspect, and perf_hooks. Add third-party tools only when you hit a real limitation — not by default.

What’s already available, with zero installs

Every capability this module covers is already inside the node binary you have. A quick self-check, run for real on Node 24:

Node.jsOpen in StackBlitz ▸

// A quick "what can I reach for without installing anything" check. import { test } from 'node:test'; import { performance } from 'node:perf_hooks'; console.log('node:test available:', typeof test === 'function'); console.log('perf_hooks available:', typeof performance.now === 'function'); console.log('global fetch available:', typeof fetch === 'function'); console.log('type stripping (.ts files) is on by default on Node 24 -- no flag needed');

Output (verified on Node 24)

node:test available: true
perf_hooks available: true
global fetch available: true
type stripping (.ts files) is on by default on Node 24 -- no flag needed

Mental Model

Each lesson in this module answers one question about the same running process — think of it as four lenses pointed at the same node binary, not four separate tools:

flowchart TB
  Q1["Is my code correct?"] -->|"node:test + node:assert"| L1["Built-in Test Runner"]
  Q2["Why did it do that?"] -->|"--inspect, console.*, uncaughtException"| L2["Debugging"]
  Q3["Is it fast enough?"] -->|"perf_hooks, --cpu-prof, worker_threads"| L3["Performance"]
  Q4["How do I run/ship it?"] -->|"--env-file, --watch, node --run, Docker"| L4["Ecosystem & Toolchain"]
  L1 --> Ship["Code you can trust in production"]
  L2 --> Ship
  L3 --> Ship
  L4 --> Ship

Four questions about the same process: correct, debuggable, fast enough, shippable

Trade-offs

Choice	Benefit	Cost
Built-in node:test / perf_hooks / --inspect	Zero install, zero config drift, works the same on every machine that has Node	Fewer conveniences than a mature ecosystem tool (no coverage UI, no watch-mode test filtering out of the box)
Third-party (Vitest, ESLint, pino, tsx)	Richer DX, plugin ecosystems, features Node hasn’t stabilized yet	A dependency to install, pin, audit, and keep updated — and a lockfile everyone must trust
Learning the built-ins first	Debugging AI-generated or unfamiliar code never depends on “which test framework does this repo use”	Slightly more typing for things a framework would give you as sugar (e.g. expect().toBe() vs assert.equal())

Common Misconceptions

• “You need Jest or Mocha to write real tests in Node” — fact: node:test has been built in since Node 18, and by Node 24 it covers mocking, fake timers, snapshots, and coverage without a single dependency.
• “TypeScript needs a build step to run on Node” — fact: Node 24 strips type annotations at load time by default; you only need tsx/ts-node/tsc for syntax that needs to be transformed (enum, decorators) rather than erased.
• “perf_hooks / node —inspect / node:test are experimental or unstable” — fact: all three are stable APIs; only specific sub-features (coverage, some test-runner extras) still carry an --experimental- flag, and each lesson calls those out explicitly.

Reading AI-generated code

• Does a snippet reach for jest/mocha/chai as a dependency for a task node:test + node:assert already cover? That’s an unnecessary dependency, not a correctness bug — but it’s a signal the generated code wasn’t written with Node 24 in mind.
• Does it add ts-node or a bundler step for a plain .ts file with only type annotations (no enum, no decorators)? node file.ts already works.
• Does it call a Node built-in behind an --experimental- flag (test coverage, module mocks) without mentioning the flag or the warning it prints? Running the snippet as shown will crash or silently no-op.

🐛 Spot the bug

import { test } from 'node:test';
import assert from 'node:assert/strict';

// package.json: "test": "node --test"
test('creates a user', async function() {
const user = await createUser({ name: 'Ada' });
assert.equal(user.name, 'Ada');
});

test.only('debugging this one locally', function() {
assert.ok(true);
});

Show the answer

test.only marks exactly one test to run exclusively — but only when the runner is invoked with --test-only (or run({ only: true })). The package.json script above is plain node --test, so without --test-only both tests still run normally, .only is a no-op, and nothing looks wrong locally. The real danger is the opposite setup: a CI script that always passes --test-only. There, forgetting to remove test.only after a debugging session silently excludes every other test in the file from ever running again — and CI stays green while regressions in the skipped tests go uncaught. Search test files for .only before every commit, or lint for it.

🟢 The one-line takeaway

Node 24 already ships a test runner, a debugger, a profiler, and a config loader — reach for a dependency only after you’ve confirmed the built-in doesn’t already do the job.

Which Node.js version introduced the built-in node:test runner?

Node 14 Node 16 Node 18 Node 22

Which built-in module is used for measuring execution time in Node.js?

node:timers node:perf_hooks node:process node:v8

How do you run a TypeScript file directly on Node 24 without a build step?

node --ts-mode src/app.ts node --allow-typescript src/app.ts node src/app.ts — type stripping is on by default node --run-ts src/app.ts

What does this print on Node 24? import { test } from 'node:test'; console.log(typeof test);

undefined function object It throws — node:test needs --experimental-test flag

A CI test script is node --test --test-only. A developer leaves test.only(...) on one test after debugging and pushes it. What happens?

CI fails immediately because .only is forbidden CI stays green, but every other test in that file silently stops running Node ignores .only entirely outside of local development .only has no effect unless describe() is also used

Why does this module teach node:test / --inspect / perf_hooks before mentioning any third-party tool?

Third-party tools are deprecated in Node 24 They are stable built-ins that work identically on every machine with Node installed, so understanding them first makes every framework on top of them easier to read Third-party tools cannot be used with TypeScript There is no reason — it is just this course's style

Submit

Mark as complete