csharp-tunit
Get best practices for TUnit unit testing, including data-driven tests
摘要
- 用途
- 协助运用一致的结构、生命周期挂钩、断言与数据驱动模式,撰写清晰可靠的 TUnit 测试。
- 使用时机
- 在设计或维护使用 TUnit 的 .NET 测试时使用,尤其是需要安排测试设置、验证行为或涵盖多种输入案例时。
- 输出结果
- 提供 TUnit 项目设置、测试组织、断言、数据源、生命周期、迁移与运行功能的实用指引。
上游变更(6 条,最新收录 2026-02-19)
caab1f6 Convert all prompts to skills and update plugin manifests 添加 csharp-tunit 技能,涵盖 TUnit 项目设置、测试结构、数据驱动测试、断言、高级功能、测试组织、性能及 xUnit 迁移。 2f9c96d Fix deprecated 'mode' attribute in prompt files by renaming to 'agent' (#441) 将提示前置数据中的字段从 `mode` 改为 `agent`,并保留其值 `agent`。 2b45ca4 feat: update deprecated tool names to namespaced versions (#365) 将提示工具清单中的 `codebase` 改为 `search/codebase`。 69cd4fa update `editFiles` to `edit/editFiles` (#319) 将提示工具清单中的 `editFiles` 改为 `edit/editFiles`,并在文件末尾添加换行。 2f3264b Add missing `mode` field to all prompt files with 'agent' as default (#180) 移除了提示 YAML 前置数据前的字节顺序标记。 05f6814 Add C# TUnit testing prompt template (#88) 添加初始的 csharp-tunit 提示,提供 TUnit 的设置、测试结构、数据驱动测试、断言、高级功能、测试组织、性能及 xUnit 迁移指南。 npx skills add "lettucebo/Skills#v2.2.0@csharp-tunit" --full-depth ⚠ v2.2.0 发布后即可使用
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.,
CalculatorTestsforCalculator) - Use .NET SDK test commands:
dotnet testfor 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()orawait Assert.That(value).IsFalse()for boolean conditions - Use
await Assert.That(collection).Contains(item)orawait 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>()orawait Assert.That(asyncAction).ThrowsAsync<TException>()to test exceptions - Chain assertions with
.Andoperator:await Assert.That(value).IsNotNull().And.IsEqualTo(expected) - Use
.Oroperator 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
TestContextfor 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 default
- Use
[Repeat(n)]with[ParallelLimit<T>]for load testing scenarios
Migration from xUnit
- Replace
[Fact]with[Test] - Replace
[Theory]with[Test]and use[Arguments]for data - Replace
[InlineData]with[Arguments] - Replace
[MemberData]with[MethodData] - Replace
Assert.Equalwithawait Assert.That(actual).IsEqualTo(expected) - Replace
Assert.Truewithawait Assert.That(condition).IsTrue() - Replace
Assert.Throws<T>withawait Assert.That(action).Throws<T>() - Replace constructor/IDisposable with
[Before(Test)]/[After(Test)] - Replace
IClassFixture<T>with[Before(Class)]/[After(Class)]
Why TUnit over xUnit?
TUnit offers a modern, fast, and flexible testing experience with advanced features not present in xUnit, such as asynchronous assertions, more refined lifecycle hooks, and improved data-driven testing capabilities. TUnit's fluent assertions provide clearer and more expressive test validation, making it especially suitable for complex .NET projects.