Skip to content
cccskills
FreePublished on GitHub

node-typescript-testing

Use when writing tests for a TypeScript service on Node.js - Vitest or the repository's Jest / node:test, fakes at port boundaries, HTTP through app.inject or supertest, Testcontainers Postgres for queries, fake timers, test-first

The English summary is being prepared. Showing the original description.

Works withPostgreSQL
See how to install

Files included (1)

  • SKILL.md4.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

TypeScript Service Testing

Overview

Test-first, same discipline as everywhere (see tdd-workflow): write the failing test, watch it fail, minimal code to pass. This skill is the Node.js mechanics for a backend.

Core principle: unit-test services and the domain with fakes for their ports; prove routes, validation and SQL against the real framework and a real database, without opening a port where the framework lets you.

Test levels

LevelWhat it coversTools
UnitDomain functions and typesthe repository's runner: Vitest, Jest or node:test
Unit with fakesService, its ports fakedvi.fn() / jest.fn() objects satisfying the port interface
HTTPRoute registration, validation, error shape, authFastify app.inject(), Nest Test.createTestingModule + supertest, supertest on an Express app
PersistenceQueries and migrations against real Postgres@testcontainers/postgresql + the repository's migrate command

Never add a second runner. A new project uses Vitest.

Unit test with a faked port

describe("TaskService.create", () => {
  const repo = { add: vi.fn<TaskRepository["add"]>().mockResolvedValue(undefined) };
  const service = new TaskService(repo);

  beforeEach(() => repo.add.mockClear());

  it("persists and returns the task", async () => {
    const task = await service.create("Write the report", "user-1");
    expect(task).toMatchObject({ title: "Write the report", ownerId: "user-1" });
    expect(repo.add).toHaveBeenCalledWith(task);
  });

  it.each(["", "   ", "x".repeat(201)])("rejects the title %j", async (title) => {
    await expect(service.create(title, "user-1")).rejects.toThrow(InvalidTaskTitle);
    expect(repo.add).not.toHaveBeenCalled();
  });
});

HTTP test without a port (Fastify)

it("answers 400 in the problem shape for a blank title", async () => {
  const app = buildApp({ taskService: fakeService });
  const res = await app.inject({ method: "POST", url: "/tasks", payload: { title: "" }, headers: auth("user-1") });
  expect(res.statusCode).toBe(400);
  expect(res.headers["content-type"]).toContain("application/problem+json");
  expect(res.json()).toMatchObject({ errors: { title: expect.any(String) } });
});

Rules

  • Fake the port, not the module. Pass fakes through the constructor or the app factory. vi.mock("../db") of your own modules couples the test to file layout; keep module mocks for third-party clients the code cannot inject.
  • Assert on the returned value or the response body first; a call assertion alone proves only that the fake ran.
  • it.each / test.each for boundary tables. One behaviour per test, named for it.
  • Time: vi.useFakeTimers() + vi.setSystemTime(...) (or Jest's) for anything date- or timeout-dependent; restore in afterEach. Never setTimeout waits in a test.
  • Real Postgres for SQL: one container per test file or suite (beforeAll), the repository's migrations applied, data truncated or rolled back between tests. Not SQLite, not pg-mem, for queries that ship to Postgres.
  • Every async assertion is awaited (await expect(...).rejects); a forgotten await passes silently.
  • Tests compile under the same strict config as the source; no as any to build a fixture — write a small builder.
  • Focused run while iterating: npx vitest run src/tasks/task.service.test.ts or -t "rejects the title"; the full npm test plus npm run typecheck before you stop. Coverage with the runner's own (vitest run --coverage); mutation testing, where the repository runs it, is StrykerJS.

Common Mistakes

  • A test that passes because the promise it checks was never awaited.
  • Fake timers left on and leaking into the next test file.
  • Snapshotting a whole response body with ids and timestamps in it — brittle, and it approves whatever the code returned.
  • Starting the real server on a fixed port in tests that run in parallel.

Red Flags

  • it.skip / it.only committed.
  • A unit test that needs Docker or the network.
  • Mocks asserting the implementation's private call order rather than its behaviour.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

Use when the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

See all skills by makifbaysal

Report a problem with this skill