dotnet-testing-autofixture-nsubstitute-integration_skill

This skill streamlines .NET testing by auto-mocking interface dependencies with AutoFixture AutoNSubstitute, reducing boilerplate and improving test resilience.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
dotnet-testing-autofixture-nsubstitute-integration skill by kevintsengtw/dotnet-testing-agent-skills | VeilStrat