Testing Node.js

After this lesson, you will be able to: Write Node tests: unit (Vitest), API tests (Supertest), integration with a test DB.

Same three layers as Python. Vitest is the modern default.

Prerequisites:Node.js in Production

Unit tests with Vitest

Fast, ESM-native.

python

// utils/parse.test.ts
import { describe, it, expect } from "vitest";
import { parseQuery } from "./parse.js";

describe("parseQuery", () => {
  it("parses limit", () => {
    expect(parseQuery({ limit: "10" })).toEqual({ limit: 10 });
  });
  it("defaults limit", () => {
    expect(parseQuery({}).limit).toBe(20);
  });
});

API tests with Supertest

Hits your Express/Fastify app directly, no real server needed.

python

import request from "supertest";
import { app } from "../app.js";

describe("GET /users", () => {
  it("returns users", async () => {
    const r = await request(app).get("/users");
    expect(r.status).toBe(200);
    expect(r.body.data).toBeInstanceOf(Array);
  });
  it("requires auth", async () => {
    const r = await request(app).post("/users").send({ name: "x" });
    expect(r.status).toBe(401);
  });
});

Integration tests with a test DB

Use a real Postgres; reset between tests.

python

import { beforeEach, afterAll, describe, it, expect } from "vitest";
import { prisma } from "../lib/db.js";
import request from "supertest";
import { app } from "../app.js";

beforeEach(async () => {
  await prisma.user.deleteMany();
});
afterAll(async () => { await prisma.$disconnect(); });

describe("user creation", () => {
  it("persists to db", async () => {
    const r = await request(app).post("/users").send({ name: "A", email: "[email protected]" });
    expect(r.status).toBe(201);
    const user = await prisma.user.findUnique({ where: { email: "[email protected]" } });
    expect(user).not.toBeNull();
  });
});

Common mistakes only experienced Node testers avoid

Mocking the database when a Docker Postgres is one container away. Integration tests catch real bugs. Running tests against prod DB. Use a separate test DB. No CI test step. Tests that don't run = tests that don't help. Brittle assertions (exact dates). Use approximations or fixed clocks.

Quick Check

Why mostly write integration tests over unit tests for Node APIs?

Pick the senior answer.

←Node.js in Production

Back to Node.js

Passion Project: REST API from Scratch→