home / skills / shotaiuchi / dotclaude / test-mock

test-mock skill

safe

This skill helps design mocks, stubs, and fixtures to isolate unit tests, ensure realistic interactions, and streamline test data factories.

npx playbooks add skill shotaiuchi/dotclaude --skill test-mock

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.1 KB

---
name: test-mock
description: >-
  Test double and fixture design. Apply when creating mock objects, stub
  responses, fake implementations, test factories, seed data, and reusable
  test fixtures.
user-invocable: false
---

# Mock/Fixture Design

Design test doubles, factories, and fixtures for reliable test infrastructure.

## Test Creation Checklist

### Mock Object Design
- Define clear interfaces for all mockable dependencies
- Configure mock return values matching realistic production data
- Set up verification for expected interaction counts and order
- Avoid over-mocking by using real implementations where practical
- Ensure mocks fail fast with descriptive error messages

### Stub & Fake Implementation
- Create lightweight fake implementations for complex dependencies
- Implement configurable stubs that support multiple test scenarios
- Verify fakes maintain behavioral parity with real implementations
- Provide error simulation modes (network failure, timeout, corruption)
- Keep fake implementations simple and avoid duplicating production logic

### Test Data Factories
- Build factories that produce valid default objects with minimal setup
- Support trait-based customization for specific test scenarios
- Ensure generated data satisfies all validation constraints
- Provide sequence generators for unique identifiers and timestamps
- Create related object graphs with proper foreign key relationships

### Fixture Management
- Organize shared fixtures by domain context, not by test file
- Implement setup/teardown that guarantees clean state between tests
- Use fixture scoping (test, class, module) appropriate to cost
- Version control seed data alongside schema migrations
- Document fixture dependencies and loading order requirements

## Output Format

Report test plan with priority ratings:

| Priority | Description |
|----------|-------------|
| Must | Core test doubles required for unit test isolation |
| Should | Factories and fixtures that reduce test boilerplate |
| Could | Convenience helpers for less common test scenarios |
| Won't | Over-engineered abstractions with limited reuse value |

Overview

This skill helps teams design test doubles, factories, and fixtures to build reliable, maintainable test infrastructure. It focuses on practical patterns for mocks, stubs, fakes, test data factories, and fixture management that reduce flakiness and boilerplate. Use it to create predictable test behavior and clear verification of interactions.

How this skill works

The skill inspects dependency boundaries and recommends clear interfaces for mockable components. It prescribes configurable stubs and simple fakes that simulate errors and edge cases, plus factories that produce valid default objects and related object graphs. It also defines fixture scoping, setup/teardown strategies, and a priority system for what to implement first.

When to use it

Unit testing modules with external or stateful dependencies
Integration tests that need repeatable seed data
When you need fast, deterministic tests that simulate failures
During test suite refactors to reduce duplication and flakiness
While creating test factories for CI-friendly data generation

Best practices

Define clear, minimal interfaces for mockable dependencies
Configure mocks to return realistic production-like values
Prefer light fakes over complex production duplication
Create factories with sensible defaults and trait-based overrides
Scope fixtures by cost and ensure setup/teardown leaves clean state
Version seed data with schema changes and document dependencies

Example use cases

Unit test a service that calls external APIs using configurable stubs that simulate timeouts and error codes
Create test factories that generate valid user accounts with related profiles and unique identifiers
Implement module-level fixtures for a database connection with teardown to truncate tables between tests
Introduce fakes for a payment processor to verify retry logic without hitting production systems
Provide verification helpers that assert call counts and call order for critical interactions

FAQ

How do I avoid over-mocking?

Mock only the boundaries that are unstable or slow; use real implementations when they are simple and fast to reduce brittle tests.

When should I use a fake vs a stub?

Use a stub for fixed, configurable responses in a test; choose a fake when you need lightweight, stateful behavior that mimics the real component without full production logic.