csharp-xunit

SKILL.md

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