- Home
- Skills
- Kevintsengtw
- Dotnet Testing Agent Skills
- Dotnet Testing Autofixture Nsubstitute Integration
dotnet-testing-autofixture-nsubstitute-integration_skill
- C#
19
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill kevintsengtw/dotnet-testing-agent-skills --skill dotnet-testing-autofixture-nsubstitute-integration- SKILL.md14.5 KB
Overview
This skill explains how to integrate AutoFixture with NSubstitute to achieve auto-mocking for .NET unit tests. It focuses on practical patterns: AutoNSubstituteCustomization, Frozen behavior, Greedy constructor strategy, and handling special dependencies like IMapper (AutoMapper/Mapster). The goal is to reduce boilerplate and keep tests focused on behavior, not object wiring.
How this skill works
The integration wires AutoFixture to create NSubstitute substitutes automatically for interfaces and abstract types using AutoNSubstituteCustomization. Marking parameters with [Frozen] ensures a single shared instance is reused for setup and verification. Custom AutoData attributes encapsulate project-specific customizations (mappers, domain builders) and InlineAutoData variants combine fixed values with auto-generated objects.
When to use it
- Testing service classes with multiple interface dependencies
- When you want automatic creation of mocks to reduce Substitute.For<T>() calls
- When you need a frozen dependency instance to configure behavior and verify interactions
- When you need consistent, reusable fixture configuration across the test suite
- When combining fixed test values with auto-generated complex objects
Best practices
- Introduce AutoFixture+NSubstitute gradually: start with simple services before expanding
- Always place [Frozen] parameters before the SUT in test method signatures
- Encapsulate project customizations (IMapper, domain factories) into a single AutoData attribute
- Prefer real mapper instances for IMapper-like dependencies via a customization rather than mocking
- Use fixture.Build().With(...) to control critical property values and keep intent explicit
Example use cases
- Verify a service method calls a repository and returns transformed result with [Frozen] repository and auto-created SUT
- Create InlineAutoData tests where the first parameters are explicit values and remaining dependencies are auto-mocked
- Define a project-level AutoDataWithCustomization to register Mapster/AutoMapper and AutoNSubstitute for consistent tests
- Test a complex object graph where AutoFixture resolves nested dependencies automatically
- Freeze a collaborator to set Returns() and assert Received() was invoked on it
FAQ
AutoFixture resolves parameters in order. If [Frozen] appears after the SUT, the SUT gets a different instance. Placing [Frozen] first ensures the SUT receives the frozen instance.
When should I use a real mapper instead of a mock?
Use a real mapper (AutoMapper/Mapster) when mapping logic is simple or critical to the behavior under test. Register it via a customization to avoid fragile mock setups.
How do I combine fixed values with auto-generated dependencies?
Use an InlineAutoData variant that wraps your AutoDataWithCustomization. Pass fixed values first; the attribute injects auto-generated dependencies for the remaining parameters.