Mocking

Use when: use test doubles correctly — mock true boundaries, not the code under test.

kimtth 8f2843c 1.1 KB Updated

File contents

Goal: fast, honest tests that isolate the unit without faking its behavior.

Use for:

  • isolating a unit from slow or external dependencies
  • deciding what to fake versus exercise for real
  • fixing brittle tests coupled to implementation

Workflow:

  1. Identify the true external boundary (network, clock, filesystem).
  2. Mock or stub only that boundary, not internal collaborators.
  3. Use the lightest double that works: stub, fake, or mock.
  4. Assert on observable behavior, not on every internal call.
  5. Keep doubles in sync with the real contract.
  6. Verify the integration with the real dependency elsewhere.

Doubles:

  • stub: returns canned data
  • fake: a working lightweight implementation
  • mock: asserts interactions occurred
  • spy: records calls for later inspection

Rules:

  • do not mock the thing you are testing
  • prefer real collaborators when they are fast and deterministic
  • avoid asserting on internal call sequences
  • verify mocked contracts against reality in integration tests

kimtth/agent-skill-100-lines-or-less/tree/main/skills/mocking commit 8f2843cb3a

Frequently asked questions

npx skillmds@latest add kimtth/mocking