testing-dotnet

Generate maintainable xUnit unit and integration tests for .NET projects.

4|Updated Apr 20, 2026
One-click install
npx skills add https://github.com/zdanovichnick/dotnet-pilot --skill testing-dotnet
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: testing-dotnet
Source: https://github.com/zdanovichnick/dotnet-pilot/tree/main/skills/testing-dotnet
Command: npx skills add https://github.com/zdanovichnick/dotnet-pilot --skill testing-dotnet

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It solves the chaos of inconsistent .NET testing practices by standardizing xUnit conventions, integration testing patterns, and test organization so generated tests behave predictably in real projects.

Core Features & Use Cases

  • Consistent test organization: Separates unit, integration, and optional architecture tests into clear project folders to keep responsibilities distinct.
  • Practical xUnit conventions: Applies standard class setup patterns (e.g., constructors, IClassFixture) and readable naming like MethodName_StateUnderTest_ExpectedBehavior.
  • Integration testing with WebApplicationFactory: Uses an isolated test host and replaces real dependencies (e.g., DB) via ConfigureTestServices to avoid fragile end-to-end setups.
  • Mocking and test data guidance: Compares Moq/NSubstitute/FakeItEasy and suggests AutoFixture or builders to reduce boilerplate while keeping intent clear.

Quick Start

Ask the assistant to generate a unit and integration test plan for your ASP.NET Core endpoint using WebApplicationFactory with an in-memory database, following the provided naming and folder conventions.

Frequently Asked Questions about testing-dotnet

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write integration tests for ASP.NET Core endpoints using WebApplicationFactory?

Integration tests for ASP.NET Core endpoints use WebApplicationFactory to spin up an isolated test host. You override real dependencies like databases via ConfigureTestServices to ensure fast, deterministic execution without fragile end-to-end setups.

What is the best way to organize xUnit unit and integration tests in a .NET project?

Organizing xUnit tests involves separating unit, integration, and optional architecture tests into clear project folders. This standardization keeps responsibilities distinct and ensures generated test suites remain maintainable and predictable across teams.

How does mocking with Moq compare to NSubstitute and FakeItEasy for .NET testing?

Mocking libraries like Moq, NSubstitute, and FakeItEasy are compared to reduce boilerplate while keeping test intent clear. Standardized patterns suggest combining these with AutoFixture or builders to generate reliable mock setups consistently.

What naming conventions should I use for xUnit tests in .NET?

xUnit testing conventions recommend the MethodName_StateUnderTest_ExpectedBehavior naming pattern. Applying this readable structure alongside standard class setup patterns like constructors and IClassFixture ensures generated tests behave predictably and remain easy to understand.

Can I enforce architecture rules with .NET dependency tests?

Architecture enforcement in .NET is supported through optional dependency tests. You can generate these tests within a dedicated project folder to validate architectural boundaries, ensuring your codebase maintains its intended structure alongside unit and integration tests.