Csharp Xunit

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