Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
acedergren avatar

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)
At a glance

write-tests capabilities & compatibility

Capabilities
unit testing · test coverage · mock setup · regression testing
Use cases
testing · debugging
Pricing
Free
From the docs

What write-tests says it does

**NEVER modify source code** — this skill writes tests only; production behavior is fixed.
SKILL.md
**If >3 tests fail on first run**: STOP. Root cause is almost certainly a mock wiring issue affecting all tests — not individual test logic.
SKILL.md
npx skills add https://github.com/acedergren/agentic-tools --skill write-tests

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs20
repo stars22
Last updatedMay 28, 2026
Repositoryacedergren/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

SKILL.mdMarkdownGitHub ↗

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-based mockImplementation instead.
  • 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.ts and match its exact mock structure — don't invent a new pattern.

Mock Strategy by Module Type

Module TypeStrategy
Route handlerTest app builder + session simulation + app.inject()
RepositoryMock DB connection + counter-based execute
Framework pluginReal framework instance + selective dependency mocks
Pure utilityNo mocks — test inputs/outputs directly
Service w/ DIMock 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=verbose

Arguments

  • $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.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.