Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
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
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
| Level | What it covers | Tools |
|---|---|---|
| Unit | Domain functions and types | the repository's runner: Vitest, Jest or node:test |
| Unit with fakes | Service, its ports faked | vi.fn() / jest.fn() objects satisfying the port interface |
| HTTP | Route registration, validation, error shape, auth | Fastify app.inject(), Nest Test.createTestingModule + supertest, supertest on an Express app |
| Persistence | Queries and migrations against real Postgres | @testcontainers/postgresql + the repository's migrate command |
Never add a second runner. A new project uses Vitest.
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();
});
});
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) } });
});
vi.mock("../db") of your own modules couples the test to file layout; keep module mocks for third-party clients the code cannot inject.it.each / test.each for boundary tables. One behaviour per test, named for it.vi.useFakeTimers() + vi.setSystemTime(...) (or Jest's) for anything date- or timeout-dependent; restore in afterEach. Never setTimeout waits in a test.beforeAll), the repository's migrations applied, data truncated or rolled back between tests. Not SQLite, not pg-mem, for queries that ship to Postgres.await expect(...).rejects); a forgotten await passes silently.strict config as the source; no as any to build a fixture — write a small builder.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.it.skip / it.only committed.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
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
日本語の概要は準備中です。原文の説明を表示しています。
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
日本語の概要は準備中です。原文の説明を表示しています。
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
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。
Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation
日本語の概要は準備中です。原文の説明を表示しています。