csharp-tunit
installsforks
How to install csharp-tunit?
github/awesome-copilot/csharp-tunit
$npx -y skills add github/awesome-copilot --skill csharp-tunitGet best practices for TUnit unit testing, including data-driven tests
SKILL.md
| 1 | # TUnit Best Practices |
| 2 | |
| 3 | Your goal is to help me write effective unit tests with TUnit, covering both standard and data-driven testing approaches. |
| 4 | |
| 5 | ## Project Setup |
| 6 | |
| 7 | - Use a separate test project with naming convention `[ProjectName].Tests` |
| 8 | - Reference TUnit package and TUnit.Assertions for fluent assertions |
| 9 | - Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`) |
| 10 | - Use .NET SDK test commands: `dotnet test` for running tests |
| 11 | - TUnit requires .NET 8.0 or higher |
| 12 | |
| 13 | ## Test Structure |
| 14 | |
| 15 | - No test class attributes required (like xUnit/NUnit) |
| 16 | - Use `[Test]` attribute for test methods (not `[Fact]` like xUnit) |
| 17 | - Follow the Arrange-Act-Assert (AAA) pattern |
| 18 | - Name tests using the pattern `MethodName_Scenario_ExpectedBehavior` |
| 19 | - Use lifecycle hooks: `[Before(Test)]` for setup and `[After(Test)]` for teardown |
| 20 | - Use `[Before(Class)]` and `[After(Class)]` for shared context between tests in a class |
| 21 | - Use `[Before(Assembly)]` and `[After(Assembly)]` for shared context across test classes |
| 22 | - TUnit supports advanced lifecycle hooks like `[Before(TestSession)]` and `[After(TestSession)]` |
| 23 | |
| 24 | ## Standard Tests |
| 25 | |
| 26 | - Keep tests focused on a single behavior |
| 27 | - Avoid testing multiple behaviors in one test method |
| 28 | - Use TUnit's fluent assertion syntax with `await Assert.That()` |
| 29 | - Include only the assertions needed to verify the test case |
| 30 | - Make tests independent and idempotent (can run in any order) |
| 31 | - Avoid test interdependencies (use `[DependsOn]` attribute if needed) |
| 32 | |
| 33 | ## Data-Driven Tests |
| 34 | |
| 35 | - Use `[Arguments]` attribute for inline test data (equivalent to xUnit's `[InlineData]`) |
| 36 | - Use `[MethodData]` for method-based test data (equivalent to xUnit's `[MemberData]`) |
| 37 | - Use `[ClassData]` for class-based test data |
| 38 | - Create custom data sources by implementing `ITestDataSource` |
| 39 | - Use meaningful parameter names in data-driven tests |
| 40 | - Multiple `[Arguments]` attributes can be applied to the same test method |
| 41 | |
| 42 | ## Assertions |
| 43 | |
| 44 | - Use `await Assert.That(value).IsEqualTo(expected)` for value equality |
| 45 | - Use `await Assert.That(value).IsSameReferenceAs(expected)` for reference equality |
| 46 | - Use `await Assert.That(value).IsTrue()` or `await Assert.That(value).IsFalse()` for boolean conditions |
| 47 | - Use `await Assert.That(collection).Contains(item)` or `await Assert.That(collection).DoesNotContain(item)` for collections |
| 48 | - Use `await Assert.That(value).Matches(pattern)` for regex pattern matching |
| 49 | - Use `await Assert.That(action).Throws<TException>()` or `await Assert.That(asyncAction).ThrowsAsync<TException>()` to test exceptions |
| 50 | - Chain assertions with `.And` operator: `await Assert.That(value).IsNotNull().And.IsEqualTo(expected)` |
| 51 | - Use `.Or` operator for alternative conditions: `await Assert.That(value).IsEqualTo(1).Or.IsEqualTo(2)` |
| 52 | - Use `.Within(tolerance)` for DateTime and numeric comparisons with tolerance |
| 53 | - All assertions are asynchronous and must be awaited |
| 54 | |
| 55 | ## Advanced Features |
| 56 | |
| 57 | - Use `[Repeat(n)]` to repeat tests multiple times |
| 58 | - Use `[Retry(n)]` for automatic retry on failure |
| 59 | - Use `[ParallelLimit<T>]` to control parallel execution limits |
| 60 | - Use `[Skip("reason")]` to skip tests conditionally |
| 61 | - Use `[DependsOn(nameof(OtherTest))]` to create test dependencies |
| 62 | - Use `[Timeout(milliseconds)]` to set test timeouts |
| 63 | - Create custom attributes by extending TUnit's base attributes |
| 64 | |
| 65 | ## Test Organization |
| 66 | |
| 67 | - Group tests by feature or component |
| 68 | - Use `[Category("CategoryName")]` for test categorization |
| 69 | - Use `[DisplayName("Custom Test Name")]` for custom test names |
| 70 | - Consider using `TestContext` for test diagnostics and information |
| 71 | - Use conditional attributes like custom `[WindowsOnly]` for platform-specific tests |
| 72 | |
| 73 | ## Performance and Parallel Execution |
| 74 | |
| 75 | - TUnit runs tests in parallel by default (unlike xUnit which requires explicit configuration) |
| 76 | - Use `[NotInParallel]` to disable parallel execution for specific tests |
| 77 | - Use `[ParallelLimit<T>]` with custom limit classes to control concurrency |
| 78 | - Tests within the same class run sequentially by default |
| 79 | - Use `[Repeat(n)]` with `[ParallelLimit<T>]` for load testing scenarios |
| 80 | |
| 81 | ## Migration from xUnit |
| 82 | |
| 83 | - Replace `[Fact]` with `[Test]` |
| 84 | - Replace `[Theory]` with `[Test]` and use `[Arguments]` for data |
| 85 | - Replace `[InlineData]` with `[Arguments]` |
| 86 | - Replace `[MemberData]` with `[MethodData]` |
| 87 | - Replace `Assert.Equal` with `await Assert.That(actual).IsEqualTo(expected)` |
| 88 | - Replace `Assert.True` with `await Assert.That(condition).IsTrue()` |
| 89 | - Replace `Assert.Throws<T>` with `await Assert.That(action).Throws<T>()` |
| 90 | - Replace constructor/IDisposable with `[Before(Test)]`/`[After(Test)]` |
| 91 | - Replace `IClassFixture<T>` with `[Before(Class)]`/`[After(Class)]` |
| 92 | |
| 93 | **Why TUnit over xUnit?** |
| 94 | |
| 95 | 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 capab |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
