testing-unit

Writes Vitest unit tests for pure functions and Connect procedures with fixture builders and hand-written database doubles.

1|Updated Jan 14, 2024
One-click install
npx skills add https://github.com/Eyhenij/rt-tools --skill testing-unit-eyhenij
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: testing-unit
Source: https://github.com/Eyhenij/rt-tools/tree/main/.claude/skills/testing-unit
Command: npx skills add https://github.com/Eyhenij/rt-tools --skill testing-unit-eyhenij

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing consistent unit tests in a Vitest and Nx workspace is error-prone: tests without scenario ids break spec checks, module mocks hide the database calls they should verify, and libs without a vitest config pass green while running nothing. This Skill encodes the exact layout and rules for unit tests so they are verifiable and consistent. ## Core Features & Use Cases - Standard test layout: One describe per function, explicit vitest imports, Russian behavior-focused it titles prefixed with a scenario id from docs/specs. - Fixture builders: Build test data with Partial<T> factory functions and module-scope shared constants instead of repeated literals. - Procedure testing: Call a Connect procedure's handle method directly with a hand-written database double (e.g. FakePrismaClient) to verify action order, rollback, and idempotence. - Use Case: When creating availability-calendar.logic.spec.ts, load this Skill to structure the describe blocks, build a day() fixture with overrides, and tag each test with its scenario id like SC-BK-19. ## Quick Start Load this Skill before creating or editing any *.spec.ts file under Vitest, then follow its layout for describes, fixtures, and procedure tests.

Frequently Asked Questions about testing-unit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How to test a Connect procedure with a database double?

Call the procedure class's handle method directly with a hand-written double such as FakePrismaClient. Verify the order of actions, rollback on partial refusal, idempotence of repeats, and exactly what was written to the database.

Should I use vi.mock to substitute modules in unit tests?

No. Module substitution hides which call went to the database and in what order, which is what the test exists to verify. Write the database double by hand instead, reusing the working set from a neighboring procedure's test.

Why does nx test pass green without running any tests?

The lib is missing its own vitest.config.mts, so the runner finds no files and reports success. Before writing the first test in a lib, confirm the config exists next to it.

When should I not use this unit testing pattern?

Do not use it for end-to-end tests, which belong to the separate testing-e2e pattern. It also does not cover temporary proof tests written during defect investigation, which are never committed.