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.
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.
Review the instructions the agent will receive before you install.
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.No reviews yet. Tell others what you thought.
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.
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.
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.
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.
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.
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.
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.