Testing Best Practices
Rules that keep Node API test suites fast, reliable, and focused on observable behavior.
Search across all documentation pages
Rules that keep Node API test suites fast, reliable, and focused on observable behavior.
npm test, separate integration job).returns 409 when invoice already paid beats test1.createApp() without auto-listen. Supertest and Fastify inject need in-process apps.EADDRINUSE and flaky CI.vi.setSystemTime or injected clock interface.npm test entry; split unit vs integration when needed. test:integration may require Docker.node:test or Vitest for new code; plan Jest exit on brownfield. Avoid three runners.typecheck and lint. Fail fast ordering in pipeline.auth disabled in test globally unless isolated unit.Implementation tests break on refactor without behavior change. HTTP/domain assertions survive internal rewrites.
Per CI job container is ideal. Minimum: separate database name and truncate between suites.
External third-party APIs and slow infra in unit tests. Prefer real Postgres in integration for SQL correctness.
Critical journeys yes (deploy smoke). Full cross-product E2E may live in separate repo - keep service integration tests here.
No shared mutable singletons; await all requests; reset modules or use fresh createApp() per test.
node:test for pure logic zero-dep; Vitest when mocking/watch/coverage dominate workflow.
One pact per consumer-provider pair covering endpoints actually called - not full API surface.
No - nightly or pre-release. Short smoke optional on release branches.
Unit test services with mocked repos; e2e Supertest for controllers; Testcontainers for DB integration.
Sparingly for stable JSON error shapes; prefer explicit field assertions for APIs.
Stack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, and NestJS 11.
Reviewed by Chris St. John·Last updated Jul 18, 2026