跳到正文
cccskills
免费在 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

中文简介正在准备中。当前显示原文说明。

集成工具PostgreSQL
查看安装方法

包含的文件(1)

  • SKILL.md4.4 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

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

中文简介正在准备中。当前显示原文说明。

makifbaysal/tasktrooper1172026年10月18日 更新

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

中文简介正在准备中。当前显示原文说明。

makifbaysal/tasktrooper1172026年10月18日 更新

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

中文简介正在准备中。当前显示原文说明。

makifbaysal/tasktrooper1172026年10月18日 更新

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

中文简介正在准备中。当前显示原文说明。

makifbaysal/tasktrooper1172026年10月18日 更新

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.

中文简介正在准备中。当前显示原文说明。

makifbaysal/tasktrooper1172026年10月18日 更新

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

中文简介正在准备中。当前显示原文说明。

makifbaysal/tasktrooper1172026年10月18日 更新

查看 makifbaysal 的全部技能

报告此技能的问题