mcpField
D
django-targeted-mocking

django-targeted-mocking

github.com/lvtd-llcTesting & quality160 installsUpdated 7w ago
Repository

About django-targeted-mocking

A Django testing skill for choosing focused, interface-aware mocks at slow, external, or nondeterministic boundaries. It guides developers toward tests that isolate dependencies without masking the behavior under test.

Key features

  1. 01Boundary-based mock decisions
  2. 02Patch dependencies at lookup sites
  3. 03Django-specific settings helpers
  4. 04Interface-checked mocks and fakes
  5. 05Block unintended outbound HTTP

Use cases

  1. 01Testing integrations with external HTTP services
  2. 02Controlling settings, time, or command output
  3. 03Avoiding mocks that hide request behavior

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/lvtd-llc/skills --skill django-targeted-mocking

After installing, type/django-targeted-mockingin Claude Code to confirm it loaded.

Bundled filesreferences/mocking-patterns.md

Details

From the project README

Django Targeted Mocking

Mock only at boundaries that are slow, nondeterministic, external, or hard to trigger. Broad mocks can make tests faster while proving less, so prefer framework helpers and interface-checked replacements.

Boundary Workflow

  1. Decide whether mocking is necessary.

    • Prefer real code for local domain logic.
    • Mock external HTTP, time, settings, output/input, and expensive service edges.

  2. Patch where the code under test looks up the dependency.

    • Patch the imported symbol used by the module under test, not the original library path unless that is what the module reads.

  3. Prefer specific tools.

    • Settings: override_settings, modify_settings, or pytest-django's settings fixture.
    • Output: io.StringIO, pytest capsys, or command test helpers.
    • HTTP: requests-mock for hand-authored responses; VCR.py for recorded responses.
    • Time: pass time as a parameter when possible; otherwise use time-machine or a similar time-specific tool.

  4. Make mocks interface-aware.

    • Use autospec=True, spec, spec_set, create_autospec, or a small fake object.
    • Avoid bare Mock/MagicMock when the interface matters.

  5. Block unexpected outbound HTTP.

    • A normal test run should fail if a test reaches the network unintentionally.

Read mocking-patterns.md for concrete patterns.

Decision Rules

  • Use Django settings helpers instead of direct assignment to django.conf.settings.
  • Prefer a hand-built fake or types.SimpleNamespace when only a few attributes are needed.
  • Use requests-mock for deterministic API responses you control.
  • Use VCR.py when real recorded responses are valuable and safe to store.
  • On CI, configure VCR record mode so missing cassettes fail instead of recording.
  • Mock time consistently across the runtime; do not patch several datetime functions by hand.
  • Do not mock the component whose behavior the test is meant to prove.

Common Mistakes

  • Patching settings directly and leaking state across tests.
  • Using catch-all MagicMock objects that accept typoed attributes and wrong call signatures.
  • Allowing tests to hit real external services.
  • Recording VCR cassettes in CI.
  • Mocking a view's internal helpers so thoroughly that the test no longer covers request behavior.
  • Patching the wrong import path and thinking the mock is active.

Verification

Before finishing:

  • Each mock has a clear boundary reason.
  • Interface-sensitive mocks use specs or fakes.
  • Unexpected outbound HTTP is blocked in the normal suite.
  • Settings are restored automatically by Django or pytest helpers.
  • Tests still cover the behavior, not only mock calls.

Comments

Markdown supported