# Exp Mock Usage Analysis

Audits .NET test mock usage by tracing each mock setup through the production code's...

- Repository: https://github.com/dotnet/skills (5787 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add dotnet/skills --skill exp-mock-usage-analysis -g -a claude-code -y`
Codex: `npx skills add dotnet/skills --skill exp-mock-usage-analysis -g -a codex -y`
Cursor: `npx skills add dotnet/skills --skill exp-mock-usage-analysis -g -a cursor -y`
Gemini CLI: `npx skills add dotnet/skills --skill exp-mock-usage-analysis -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add dotnet/skills`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Mock Usage Analysis

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.

## When to Use

- User asks to audit, review, or analyze mock usage in .NET tests
- User wants to find unused, unnecessary, or redundant mock setups
- User wants to simplify test setup or reduce over-mocking
- User asks whether mocks of ILogger, IOptions, or similar types are needed

## When Not to Use

- User wants to write new mocks or tests (general testing guidance)
- User wants to detect non-mock test anti-patterns (use `test-anti-patterns`)
- User wants to migrate between mock frameworks (out of scope)

## Inputs

| Input | Required | Description |
|-------|----------|-------------|
| Test code | Yes | Test files to analyze |
| Production code | Yes | Code under test, essential for tracing execution paths |

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

The rest: https://github.com/dotnet/skills/blob/HEAD/plugins/dotnet-experimental/skills/exp-mock-usage-analysis/SKILL.md