csharp-xunit

name	csharp-xunit
description	Get best practices for XUnit unit testing, including data-driven tests

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.v3, and xunit.runner.visualstudio packages
• Test projects must set <OutputType>Exe</OutputType> (xUnit v3 requirement)
• 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 MethodUnderTest_Scenario_ExpectedOutcome
• 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 behaviour
• Avoid testing multiple behaviours 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
• Do not use FluentAssertions, AwesomeAssertions, Shouldly, Moq, NUnit, or MSTest — see DEC-006 and DEC-016. Use xUnit's built-in Assert.* methods exclusively.

Mocking and Isolation

• Use NSubstitute alongside xUnit v3 for mocking dependencies
• Create substitutes with Substitute.For<TInterface>()
• Verify calls with Received() and DidNotReceive()
• Mock dependencies to isolate units under test
• Use interfaces to facilitate mocking
• Consider using a DI container for complex test setups

Test Organisation

• 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