Node.js Testing

Build the smallest reliable test suite that matches the application's real risks. Preserve a working test stack unless the user explicitly asks to replace it.

Confirm before changing

Inspect read-only first. Before writing files, installing packages, updating configuration, generating coverage, or running a command that may change state, show a proposal of no more than five short bullets covering the tests to add, files or areas affected, tools/packages, verification, and anything intentionally excluded. Wait for confirmation, then perform only the approved work. Do not repeat documentation or narrate routine steps unless asked.

Inspect before choosing tools

Read package.json, lockfiles, test configuration, application entrypoints, routes, services, database setup, authentication, and existing tests. Identify:

• runtime, module system, TypeScript execution, framework, and package manager;
• the existing runner and assertion/mocking tools;
• boundaries that can be tested without starting a network listener;
• stateful dependencies such as databases, caches, queues, object storage, and provider APIs;
• critical flows and failure cases.

If there is no runner, prefer the stable built-in node:test runner for a small dependency-light project. Prefer Vitest when the project benefits from TypeScript-first configuration, familiar mocking, workspaces, or richer coverage. Install current packages through the package manager; never invent versions.