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