Loading
Audits .NET test mock usage by tracing each mock setup through the production code's execution path to find dead, unreachable, redundant, or replaceable mocks. Use when the user asks to audit mock usa
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add dotnet/skills --skill exp-mock-usage-analysis -a cursor -y
Audits .NET test mock usage by tracing each mock setup through the production code's execution path to find dead, unreachable, redundant, or replaceable mocks. Use when the user asks to audit mock usage, find unused or unnecessary mock setups, check if mocks are needed, reduce mock duplication or over-mocking, simplify test setup, or review whether mock configurations like ILogger/IOptions should use real implementations instead. Supports Moq, NSubstitute, and FakeItEasy.
Audits .NET test mock usage by tracing each mock setup through the production code's execution path to find dead, unreachable, redundant, or replaceable mocks. Use when the user asks to audit mock usage, find unused or unnecessary mock setups, check if mocks are needed, reduce mock duplication or over-mocking, simplify test setup, or review whether mock configurations like ILogger/IOptions should use real implementations instead. Supports Moq, NSubstitute, and FakeItEasy.
Trace each mock setup through the production code's execution path to determine which setups are actually exercised at runtime and which are dead, unreachable, redundant, or replaceable with real implementations.
test-anti-patterns)| Input | Required | Description |
|---|---|---|
| Test code | Yes | Test files to analyze |
| Production code | Yes | Code under test — essential for tracing execution paths |
Read the test files and always read the production code. You cannot determine whether a mock setup is necessary without understanding the production method's control flow.
Identify the mock framework by scanning for its patterns:
new Mock<T>(), .Setup(...), .Verify(...)Substitute.For<T>(), .Returns(...), .Received(...)A.Fake<T>(), A.CallTo(...), .MustHaveHappened()Use the correct framework's terminology throughout your analysis.
For each test method, do the following:
.Setup, .Returns, A.CallTo, etc.)| Classification | Meaning | Example |
|---|---|---|
| Used | The production code calls this mock during the test's execution path | GetStock setup when Reserve is called and stock is sufficient |
| Unreachable | The production code returns early, throws, or branches away before reaching this mock call | UpdateStock setup when the test expects the method to throw ArgumentOutOfRangeException on the first line |
| Unused | The mock method is never called by the production method under test at all, regardless of inputs | GetLowStockProducts setup when testing Reserve, which never calls that method |
| Redundant | Identical mock configurations are duplicated across multiple tests instead of being shared | Five tests each creating new Mock<IPaymentGateway>() with the same default setup |
Pay special attention to:
.Verify/.Received/.MustHaveHappened without asserting on the method's return valueFlag mocks of stable framework types that should use real implementations:
Mock<ILogger<T>> → NullLogger<T>.Instance (unless log output is asserted)Mock<IOptions<T>> → Options.Create(new T { ... })new T { ... } directlyExplicitly confirm which mocks are correctly placed — external boundaries (databases, HTTP clients, message queues, third-party APIs) and security-sensitive types should remain mocked.
For each finding, state:
When multiple tests duplicate mock configurations, provide a before/after example showing how to extract shared setup into a fixture or helper method.
| Pitfall | Solution |
|---|---|
| Analyzing test code without reading production code | Always read the production method to trace which mocks are actually called |
| Flagging mocks for external boundaries (HTTP, DB) | These are valid isolation boundaries — keep them mocked |
Flagging ILogger mock when log output is asserted | Only flag when the mock is set up but log output is never verified |
| Using wrong framework terminology | Match the framework in the code: Moq (Setup/Verify), NSubstitute (Returns/Received), FakeItEasy (A.CallTo/MustHaveHappened) |