fdt-refactor-mock-to-fake

Refactor unittest.mock-based tests into gateway-injected fakes with pre-canned responses.

2|Updated Apr 2, 2026
One-click install
npx skills add https://github.com/nseng-ai/ns --skill fdt-refactor-mock-to-fake-nseng-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fdt-refactor-mock-to-fake
Source: https://github.com/nseng-ai/ns/tree/main/.agents/skills/fdt-refactor-mock-to-fake
Command: npx skills add https://github.com/nseng-ai/ns --skill fdt-refactor-mock-to-fake-nseng-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Tests that rely on unittest.mock.patch and MagicMock are brittle, tightly coupled to implementation details, and hard to maintain. This Skill guides a structured refactoring that replaces mocks with injectable gateway abstractions and configurable fakes, making tests more robust and intention-revealing. ## Core Features & Use Cases - Mock Auditing: Systematically catalogs every patch() call in a test file, grouping mocks by the system boundary (tool or service) they simulate. - Gateway Discovery: Searches existing gateway ABCs and fakes at the right abstraction level, avoiding low-level wrappers around subprocess.run. - Source Injection & Test Rewriting: Adds constructor or Click-context injection of gateways to source code, then rewrites tests to use fakes with pre-canned responses and call-tracking assertions. - Use Case: A test patches shutil.which and subprocess.run to simulate the Claude CLI. The Skill identifies PromptExecutor as the correct gateway, injects it into the class under test, and rewrites the test using FakePromptExecutor with configured PromptResult values. ## Quick Start Ask the agent to refactor the tests in a given test file that use unittest.mock.patch into the gateway-based fake pattern.

Frequently Asked Questions about fdt-refactor-mock-to-fake

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I replace unittest.mock.patch with dependency injection in Python tests?

Audit each patch() call to identify the system boundary it simulates, find or create a gateway ABC for that tool, inject it via the constructor of the class under test, and rewrite tests to configure a fake with pre-canned responses instead of mocking.

What is the difference between a mock and a fake in testing?

A mock patches functions at call sites and asserts on invocation, coupling tests to implementation details. A fake is a working implementation of a gateway interface with constructor-injected test data and call tracking, so tests assert on recorded behavior rather than patched internals.

Why should I avoid mocking subprocess.run directly?

Mocking subprocess.run tests at the wrong abstraction level and breaks when implementation details change. The gateway should be named after the tool being invoked, such as a GitHub or CLI gateway, so tests express intent rather than shell mechanics.

Can I keep using pytest monkeypatch alongside fakes?

Yes. pytest's monkeypatch fixture, such as monkeypatch.delenv for environment variables, is not unittest.mock and does not need replacement. Only unittest.mock.patch and MagicMock usage should be refactored into gateway fakes.

What should I do when no gateway exists for the mocked system boundary?

Create a new gateway following the ABC, real implementation, and fake file pattern, then wire it into the application's context object with a fake default for tests and a real implementation for production before rewriting the tests.