csharp-tunit
Helps your agent write efficient C# unit tests using TUnit. It teaches best practices, including how to create tests that use varied data.
What it does
This guide teaches how to write effective code tests using TUnit, a tool to check if your program works correctly. It covers standard tests and tests with varied data.
When to use it
- ✓When creating tests to verify specific functionalities.
- ✓When needing to test code with many different scenarios.
- ✓When migrating from another testing tool like xUnit.
Example of what to ask your AI
“How do I set up a new test project with TUnit?”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
TUnit helps organize your code tests. You write tests that follow a pattern (arrange, act, assert) and use special attributes to define how and when they run, as well as verify the results.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add github/awesome-copilot --skill csharp-tunitOr download just the file:
curl -L https://raw.githubusercontent.com/github/awesome-copilot/main/skills/csharp-tunit/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
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()
…
FAQ
What are 'data-driven' tests?
These are tests that run multiple times with different data, without you needing to write the same test repeatedly. It's like having a test that multiplies itself with varied information.
How do I check if something went wrong in a test?
You use commands like 'Assert.That(value).IsEqualTo(expected)' to compare the actual result with what you expected. If they don't match, the test fails.
Can I run tests in parallel?
Yes, TUnit runs tests in parallel by default to speed up execution, but you can control which ones run together or separately.
Details
Original description by the author
Get best practices for TUnit unit testing, including data-driven tests
repo: github/awesome-copilot
Popularity
- GitHub stars
- 40k
- Ranking position
- #5098
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
acquire-codebase-knowledge
Helps your agent understand and document an existing code project. It's useful for onboarding new people or getting an overview of the architecture.
github/awesome-copilot
acreadiness-assess
Enables your agent to assess a project's readiness for AI and generate a report. It's useful for understanding how well a project is prepared to use AI tools.
github/awesome-copilot
acreadiness-generate-instructions
Helps your agent create instructions for AI tools based on an assessment. It's useful for improving how AI interacts with code and closing identified gaps.
github/awesome-copilot
acreadiness-policy
Enables your agent to help define or apply policies for AI project assessment. It's useful for standardizing how projects are evaluated and ensuring compliance.
github/awesome-copilot
Similar skills
cpp-testing
Makes your agent write and improve tests for C++ code. It helps set up testing tools and fix errors.
affaan-m/ECC
csharp-testing
Helps your agent create tests for C# and .NET code. It uses best practices to ensure tests are efficient and reliable.
affaan-m/ECC
django-tdd
Enables your agent to apply testing strategies for Django with pytest-django and TDD. It's useful for writing robust tests and ensuring code quality, especially for DRF APIs.
affaan-m/ECC