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.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](../../plan/DECISIONS.md#dec-006-no-fluentassertions--xunit-built-in-assertions-only) and [DEC-016](../../plan/DECISIONS.md#dec-016-formalised-testing-standard--xunit-v3-nsubstitute-playwright-e2e). 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