Mock Usage Analysis

Workflow

Step 1: Read all provided code

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:

• Moq: new Mock<T>(), .Setup(...), .Verify(...)
• NSubstitute: Substitute.For<T>(), .Returns(...), .Received(...)
• FakeItEasy: A.Fake<T>(), A.CallTo(...), .MustHaveHappened()

Use the correct framework's terminology throughout your analysis.

Step 2: Trace each mock setup through the production code

For each test method, do the following:

1. Identify every mock setup line (.Setup, .Returns, A.CallTo, etc.)
2. Read the production method being tested and trace its execution path for the specific inputs used in that test
3. Determine which mock setups are actually reached during execution
4. Classify each setup:

| 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:

• Early returns and guard clauses — setups for mocks called after a guard clause are unreachable when the guard triggers
• Exception throws — if the method throws before using dependencies, all setups for those dependencies are unnecessary
• Branch-specific logic — if a method dispatches by channel/type, setups for other channels are unused
• Verify-only tests — tests that only call .Verify/.Received/.MustHaveHappened without asserting on the method's return value

Step 3: Check for replaceable mocks

Flag 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 { ... })
• Mocks of DTOs, records, or value objects → use new T { ... } directly

Explicitly confirm which mocks are correctly placed — external boundaries (databases, HTTP clients, message queues, third-party APIs) and security-sensitive types should remain mocked.

Step 4: Report findings

For each finding, state:

1. The specific test method and mock setup line
2. Why the setup is unnecessary (trace the production code path to explain)
3. A concrete fix — which lines to remove, what to replace them with, or how to extract shared setup

When multiple tests duplicate mock configurations, provide a before/after example showing how to extract shared setup into a fixture or helper method.

Related skills