Documentation

See here: https://thomhurst.github.io/TUnit/

Modern and Fast

TUnit leverages source generators to locate and register your tests as opposed to reflection. You'll have a slight bump in build time, but a speedier runtime.

TUnit also builds upon the newer Microsoft.Testing.Platform, whereas most other frameworks you'll have used will use VSTest. The new platform was reconstructed from the ground up to address pain points, be more extensible, and be faster.

Hooks, Events and Lifecycles

One of the most powerful parts of TUnit is the information you have available to you because of the source generation and the events you can subscribe to. Because tests are constructed at the point of discovery, and not at runtime, you know all your arguments, properties, etc. upfront.

You can then register to be notified about various events such as test registered (scheduled to run in this test session at some point in the future), test started, test finished, etc.

Say we injected an external object into our tests: By knowing how many tests are registered, we could count them up, and then on a test end event, we could decrease the count. When hitting 0, we know our object isn't going to be used by any other tests, so we can dispose of it. We know when we can handle the lifecycle, and this prevents it from living till the end of the test session where it could be hanging on to precious resources.

Built in Analyzers

TUnit tries to help you write your tests correctly with analyzers. If something isn't quite right, an analyzer should tell you what's wrong.

IDE

TUnit is built on top of the newer Microsoft.Testing.Platform, as opposed to the older VSTest platform. Because the infrastructure behind the scenes is new and different, you may need to enable some settings. This should just be a one time thing.

Visual Studio

Visual Studio is supported. The "Use testing platform server mode" option must be selected in Tools > Manage Preview Features.

Rider

Rider is supported. The Enable Testing Platform support option must be selected in Settings > Build, Execution, Deployment > Unit Testing > VSTest.

VS Code

Visual Studio Code is supported.

• Install the extension Name: C# Dev Kit
• Go to the C# Dev Kit extension's settings
• Enable Dotnet > Test Window > Use Testing Platform Protocol

CLI

dotnet CLI - Fully supported. Tests should be runnable with dotnet test, dotnet run, dotnet exec or executing an executable directly. See the docs for more information!

Packages

TUnit.Core

To be used when you want to define re-useable components, such as a test library, but it wouldn't be run as its own test suite.

TUnit.Engine

For test suites. This contains the test execution logic and test adapter. Only install this on actual test projects you intend to run, not class libraries.

TUnit.Assertions

This is independent from the framework and can be used wherever - Even in other test frameworks. It is just an assertion library used to assert data is as you expect. It uses an asychronous syntax which may be different to other assertion libraries you may have used.

TUnit

This is a helper package to combine the above 3 packages. If you just want a standard test app where you can write, run and assert tests, just install this!

TUnit.Playwright

This provides you base classes, similarly to Microsoft.Playwright.NUnit or Microsoft.Playwright.MSTest, to automatically create and dispose of Playwright objects in tests, to make it easier for you to write tests without worrying about lifecycles or disposing. The base classes are named the same as the other libraries: PageTest, ContextTest, BrowserTest, and PlaywrightTest.

Features

• Native AOT / Trimmed Single File application support
• Source generated tests
• Property injection
• Full async support
• Parallel by default, with mechanisms to:
  • Run specific tests completely on their own
  • Run specific tests not in parallel with other specific tests
  • Limit the parallel limit on a per-test, class or assembly level
• Tests can depend on other tests to form chains, useful for if one test depends on state from another action. While not recommended for unit tests, this can be useful in integration testing where state matters
• Easy to read assertions - though you're also free to use whichever assertion library you like
• Injectable test data via classes, methods, compile-time args, or matrices
• Hooks before and after:
  • TestDiscover
  • TestSession
  • Assembly
  • Class
  • Test
• Designed to avoid common pitfalls such as leaky test states
• Dependency injection support (See here)
• Ability to view and interrogate metadata and results from various assembly/class/test context objects

Installation

dotnet add package TUnit --prerelease

Example test

or with more complex test orchestration needs

Motivations

TUnit is inspired by NUnit and xUnit - two of the most popular testing frameworks for .NET.

It aims to build upon the useful features of both while trying to address any pain points that they may have.

Read more here

Prerelease

You'll notice that version 1.0 isn't out yet. While this framework is mostly feature complete, I'm waiting for a few things:

• Full Rider support for all features
• Full VS support for all features
• Open to feedback on existing features
• Open to ideas on new features

As such, the API may change. I'll try to limit this but it's a possibility.

Benchmark

Scenario: Building the test project

macos-latest

ubuntu-latest

windows-latest

Scenario: A single test that completes instantly (including spawning a new process and initialising the test framework)

macos-latest

ubuntu-latest

windows-latest

Scenario: A test that takes 50ms to execute, repeated 100 times (including spawning a new process and initialising the test framework)

macos-latest

ubuntu-latest

windows-latest