| agent |
agent |
| tools |
changes |
search/codebase |
edit/editFiles |
problems |
search |
|
| description |
Get best practices for XUnit unit testing, including data-driven tests |
Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.
- 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
- 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
- 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
- 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
- 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
- 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
- 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