exp-mock-usage-analysis

Audits .NET test mock setups by tracing production code execution paths to find dead or redundant mocks.

1|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/D1ssolve/craft-agents --skill exp-mock-usage-analysis-d1ssolve
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: exp-mock-usage-analysis
Source: https://github.com/D1ssolve/craft-agents/tree/main/skills/exp-mock-usage-analysis
Command: npx skills add https://github.com/D1ssolve/craft-agents --skill exp-mock-usage-analysis-d1ssolve

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? .NET test suites often accumulate mock setups that are never exercised, unreachable due to guard clauses, duplicated across tests, or mocking types that should use real implementations, making tests harder to maintain and slower to understand. ## Core Features & Use Cases - Execution Path Tracing: Traces each mock setup through the production method's control flow to classify it as used, unreachable, unused, or redundant. - Replaceable Mock Detection: Flags mocks of stable framework types like ILogger and IOptions that should use NullLogger or Options.Create instead, while confirming external boundaries stay mocked. - Multi-Framework Support: Recognizes Moq, NSubstitute, and FakeItEasy patterns and uses the correct framework terminology in findings. - Use Case: A team inherits a large test suite with heavy over-mocking; run this audit to get a per-test report of which setups to delete, which to consolidate into shared fixtures, and which to replace with real implementations. ## Quick Start Audit the mock usage in my OrderService tests by tracing each setup through the production code and telling me which mocks are unnecessary.

Frequently Asked Questions about exp-mock-usage-analysis

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

FAQPage Schema
How do I find unused mock setups in .NET tests?

Trace each mock setup through the production method's execution path for the specific test inputs. Setups for methods never called by the code under test are unused, and setups after guard clauses or early returns are unreachable.

Should I mock ILogger in unit tests?

Mock ILogger only when log output is explicitly asserted or verified. Otherwise replace Mock<ILogger<T>> with NullLogger<T>.Instance, which removes setup noise without changing behavior.

Does this mock analysis support NSubstitute and FakeItEasy?

Yes, the analysis recognizes Moq (Setup/Verify), NSubstitute (Returns/Received), and FakeItEasy (A.CallTo/MustHaveHappened) patterns and reports findings using the correct framework's terminology.

When should mocks not be removed from tests?

Mocks at external boundaries such as databases, HTTP clients, message queues, and third-party APIs should remain, as they are valid isolation points. Security-sensitive types should also stay mocked.

Why is reading production code required for mock analysis?

You cannot determine whether a mock setup is exercised without knowing the production method's control flow. Guard clauses, exceptions, and branch-specific dispatch determine which setups are reachable for a given test's inputs.