
Write Tests
- 20 installs
- 22 repo stars
- Updated May 28, 2026
- acedergren/agentic-tools
write-tests is a Claude Code skill that adds test coverage to existing source code without changing production behavior, selecting a mock strategy by module type.
About
This skill adds or improves test coverage for existing source code without changing production behavior. It selects a mock strategy by module type, handles mockReset:true environments, and prevents common vitest and jest mock-wiring failures. A developer uses it to cover an untested module or add regression tests. It tests observable behavior through the public API rather than implementation details.
- Adds test coverage to existing code without changing production behavior
- Selects mock strategy by module type (route handler, repository, plugin, utility, service)
- Handles vitest/jest mockReset:true wiring failures with hoisted and globalThis patterns
Write Tests by the numbers
- 20 all-time installs (skills.sh)
- Ranked #1,436 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
write-tests capabilities & compatibility
- Capabilities
- unit testing · test coverage · mock setup · regression testing
- Use cases
- testing · debugging
- Pricing
- Free
What write-tests says it does
**NEVER modify source code** — this skill writes tests only; production behavior is fixed.
**If >3 tests fail on first run**: STOP. Root cause is almost certainly a mock wiring issue affecting all tests — not individual test logic.
npx skills add https://github.com/acedergren/agentic-tools --skill write-testsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 20 |
|---|---|
| repo stars | ★ 22 |
| Last updated | May 28, 2026 |
| Repository | acedergren/agentic-tools ↗ |
What it does
Add regression tests to an existing module without changing its production behavior.
Who is it for?
Adding regression coverage to an untested module and wiring vitest/jest mocks correctly under mockReset:true.
Skip if: Modifying source code or driving test-first development, which the tdd skill handles.
When should I use this skill?
When adding or improving test coverage for existing source code without changing behavior.
What you get
Existing modules gain behavior-level tests with a mock strategy matched to the module type.
- Regression tests for existing code
- Correctly wired mocks
By the numbers
- 5-row mock-strategy-by-module-type table
- 6 NEVER rules
Files
Write Tests for Existing Code
When to Use
Load this skill when the user request matches the frontmatter description for Write Tests for Existing Code.
NEVER
- NEVER chain `mockResolvedValueOnce` when
mockReset: true— the chain clears between tests. Use counter-basedmockImplementationinstead. - NEVER define mock variables at module scope then reference them inside `vi.mock()` factories — hoisting creates a temporal dead zone. Use
vi.hoisted()or globalThis registry. - NEVER `vi.importActual()` for modules with side effects — use selective re-exports instead.
- NEVER test implementation details (private state, internal call order) — test observable behavior through the public API.
- NEVER copy mock patterns from other projects — check YOUR test runner config first (
mockReset,mockClear,restoreMocks). - NEVER modify source code — this skill writes tests only; production behavior is fixed.
Before Writing, Ask Yourself
- Module type? Each has a different mock strategy (see table below).
- Blast radius? Does this module have side effects (DB writes, API calls, filesystem) that need isolation?
- Nearest test file? Find the closest
*.test.tsand match its exact mock structure — don't invent a new pattern.
Mock Strategy by Module Type
| Module Type | Strategy |
|---|---|
| Route handler | Test app builder + session simulation + app.inject() |
| Repository | Mock DB connection + counter-based execute |
| Framework plugin | Real framework instance + selective dependency mocks |
| Pure utility | No mocks — test inputs/outputs directly |
| Service w/ DI | Mock injected deps via forwarding pattern |
Mock Setup (mockReset: true)
If your test runner uses mockReset: true, most examples from the internet will silently fail — return values clear between tests.
const { mockFn } = vi.hoisted(() => ({
mockFn: vi.fn(),
}));
vi.mock("./dependency", () => ({
dependency: (...args: unknown[]) => mockFn(...args),
}));
beforeEach(() => {
// MUST reconfigure here — mockReset clears return values between tests
mockFn.mockResolvedValue(defaultResult);
});For complex TDZ cases (multiple interdependent mocks), use the globalThis registry pattern:
vi.mock("./dep", () => {
if (!(globalThis as any).__mocks) (globalThis as any).__mocks = {};
const m = { dep: vi.fn() };
(globalThis as any).__mocks.dep = m;
return { dep: (...a: unknown[]) => m.dep(...a) };
});
// In tests: const mocks = (globalThis as any).__mocks;Metacognitive Rule
If >3 tests fail on first run: STOP. Root cause is almost certainly a mock wiring issue affecting all tests — not individual test logic. Re-examine the mock setup holistically before fixing tests one by one.
Run
npx vitest run <test-file> --reporter=verboseArguments
$ARGUMENTS: Path to the source file or module to cover- Example:
/write-tests src/routes/admin/settings.ts - If empty: ask the user which file needs test coverage
Related skills
FAQ
What should tests assert?
Observable behavior through the public API, never implementation details like private state or internal call order.
What if more than 3 tests fail on first run?
Stop; the root cause is almost certainly a mock-wiring issue affecting all tests, not individual test logic.