mcpField
C
csharp-xunit

csharp-xunit

github.com/midudevTesting & quality7.0k57 installsUpdated 1w ago
Repository

About csharp-xunit

A best-practices reference for C# developers writing unit tests with xUnit. It explains test structure, fixtures, data-driven tests, assertions, and isolation using mocks.

Key features

  1. 01xUnit project setup
  2. 02Fact and AAA test structure
  3. 03Fixtures and test lifecycle
  4. 04Theory and data source patterns
  5. 05Assertion and exception testing
  6. 06Mocking and test organization

Use cases

  1. 01Setting up a .NET xUnit test project
  2. 02Sharing context with fixtures
  3. 03Writing parameterized tests
  4. 04Isolating units with mocked dependencies

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/midudev/autoskills --skill csharp-xunit

After installing, type/csharp-xunitin Claude Code to confirm it loaded.

Details

From the project README

XUnit Best Practices

Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.

Project Setup

  • Use a separate test project with naming convention [ProjectName].Tests
  • Reference Microsoft.NET.Test.Sdk, xunit, and xunit.runner.visualstudio packages
  • Create test classes that match the classes being tested (e.g., CalculatorTests for Calculator)
  • Use .NET SDK test commands: dotnet test for running tests

Test Structure

  • No test class attributes required (unlike MSTest/NUnit)
  • Use fact-based tests with [Fact] attribute for simple tests
  • Follow the Arrange-Act-Assert (AAA) pattern
  • Name tests using the pattern MethodName_Scenario_ExpectedBehavior
  • Use constructor for setup and IDisposable.Dispose() for teardown
  • Use IClassFixture<T> for shared context between tests in a class
  • Use ICollectionFixture<T> for shared context between multiple test classes

Standard Tests

  • Keep tests focused on a single behavior
  • Avoid testing multiple behaviors in one test method
  • Use clear assertions that express intent
  • Include only the assertions needed to verify the test case
  • Make tests independent and idempotent (can run in any order)
  • Avoid test interdependencies

Data-Driven Tests

  • Use [Theory] combined with data source attributes
  • Use [InlineData] for inline test data
  • Use [MemberData] for method-based test data
  • Use [ClassData] for class-based test data
  • Create custom data attributes by implementing DataAttribute
  • Use meaningful parameter names in data-driven tests

Assertions

  • Use Assert.Equal for value equality
  • Use Assert.Same for reference equality
  • Use Assert.True/Assert.False for boolean conditions
  • Use Assert.Contains/Assert.DoesNotContain for collections
  • Use Assert.Matches/Assert.DoesNotMatch for regex pattern matching
  • Use Assert.Throws<T> or await Assert.ThrowsAsync<T> to test exceptions
  • Use fluent assertions library for more readable assertions

Mocking and Isolation

  • Consider using Moq or NSubstitute alongside XUnit
  • Mock dependencies to isolate units under test
  • Use interfaces to facilitate mocking
  • Consider using a DI container for complex test setups

Test Organization

  • Group tests by feature or component
  • Use [Trait("Category", "CategoryName")] for categorization
  • Use collection fixtures to group tests with shared dependencies
  • Consider output helpers (ITestOutputHelper) for test diagnostics
  • Skip tests conditionally with Skip = "reason" in fact/theory attributes

Comments

Markdown supported