Csharp-Tunit

# TUnit Best Practices

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

Project Setup

- Use a separate test project with naming convention `[ProjectName].Tests`

- Reference TUnit package and TUnit.Assertions for fluent assertions

- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)

- Use .NET SDK test commands: `dotnet test` for running tests

- TUnit requires .NET 8.0 or higher

Test Structure

- No test class attributes required (like xUnit/NUnit)

- Use `[Test]` attribute for test methods (not `[Fact]` like xUnit)

- Follow the Arrange-Act-Assert (AAA) pattern

- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`

- Use lifecycle hooks: `[Before(Test)]` for setup and `[After(Test)]` for teardown

- Use `[Before(Class)]` and `[After(Class)]` for shared context between tests in a class

- Use `[Before(Assembly)]` and `[After(Assembly)]` for shared context across test classes

- TUnit supports advanced lifecycle hooks like `[Before(TestSession)]` and `[After(TestSession)]`

Standard Tests

- Keep tests focused on a single behavior

- Avoid testing multiple behaviors in one test method

- Use TUnit's fluent assertion syntax with `await Assert.That()`

- Include only the assertions needed to verify the test case

- Make tests independent and idempotent (can run in any order)

- Avoid test interdependencies (use `[DependsOn]` attribute if needed)

Data-Driven Tests

- Use `[Arguments]` attribute for inline test data (equivalent to xUnit's `[InlineData]`)

- Use `[MethodData]` for method-based test data (equivalent to xUnit's `[MemberData]`)

- Use `[ClassData]` for class-based test data

- Create custom data sources by implementing `ITestDataSource`

- Use meaningful parameter names in data-driven tests

- Multiple `[Arguments]` attributes can be applied to the same test method

Assertions

- Use `await Assert.That(value).IsEqualTo(expected)` for value equality

- Use `await Assert.That(value).IsSameReferenceAs(expected)` for reference equality

- Use `await Assert.That(value).IsTrue()` or `await Assert.That(value).IsFalse()` for boolean conditions

- Use `await Assert.That(collection).Contains(item)` or `await Assert.That(collection).DoesNotContain(item)` for collections

- Use `await Assert.That(value).Matches(pattern)` for regex pattern matching

- Use `await Assert.That(action).Throws<TException>()` or `await Assert.That(asyncAction).ThrowsAsync<TException>()` to test exceptions

- Chain assertions with `.And` operator: `await Assert.That(value).IsNotNull().And.IsEqualTo(expected)`

- Use `.Or` operator for alternative conditions: `await Assert.That(value).IsEqualTo(1).Or.IsEqualTo(2)`

- Use `.Within(tolerance)` for DateTime and numeric comparisons with tolerance

- All assertions are asynchronous and must be awaited

Advanced Features

- Use `[Repeat(n)]` to repeat tests multiple times

- Use `[Retry(n)]` for automatic retry on failure

- Use `[ParallelLimit<T>]` to control parallel execution limits

- Use `[Skip("reason")]` to skip tests conditionally

- Use `[DependsOn(nameof(OtherTest))]` to create test dependencies

- Use `[Timeout(milliseconds)]` to set test timeouts

- Create custom attributes by extending TUnit's base attributes

Test Organization

- Group tests by feature or component

- Use `[Category("CategoryName")]` for test categorization

- Use `[DisplayName("Custom Test Name")]` for custom test names

- Consider using `TestContext` for test diagnostics and information

- Use conditional attributes like custom `[WindowsOnly]` for platform-specific tests

Performance and Parallel Execution

- TUnit runs tests in parallel by default (unlike xUnit which requires explicit configuration)

- Use `[NotInParallel]` to disable parallel execution for specific tests

- Use `[ParallelLimit<T>]` with custom limit classes to control concurrency

- Tests within the same class run sequentially by defaul