csharp-tunit

Original：🇺🇸 English

Translated

Get best practices for TUnit unit testing, including data-driven tests

7.2kinstalls

Sourcegithub/awesome-copilot

Added on2026-02-27

NPX Install

npx skill4agent add github/awesome-copilot csharp-tunit

SKILL.md Content

View Translation Comparison →

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()

await Assert.That(value).IsFalse()

for boolean conditions

Use

await Assert.That(collection).Contains(item)

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>()

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 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.Equal

with

await Assert.That(actual).IsEqualTo(expected)

Replace

Assert.True

with

await Assert.That(condition).IsTrue()

Replace

Assert.Throws<T>

with

await 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.

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()

await Assert.That(value).IsFalse()

for boolean conditions

Use

await Assert.That(collection).Contains(item)

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>()

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

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.Equal

with

await Assert.That(actual).IsEqualTo(expected)

Replace

Assert.True

with

await Assert.That(condition).IsTrue()

Replace

Assert.Throws<T>

with

await 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?

csharp-tunit

NPX Install

Tags

SKILL.md Content

TUnit Best Practices

Project Setup

Test Structure

Standard Tests

Data-Driven Tests

Assertions

Advanced Features

Test Organization

Performance and Parallel Execution

Migration from xUnit

csharp-tunit

NPX Install

Tags

SKILL.md Content

TUnit Best Practices

Project Setup

Test Structure

Standard Tests

Data-Driven Tests

Assertions

Advanced Features

Test Organization

Performance and Parallel Execution

Migration from xUnit