Assuming you have the .NET SDK installed, simply run:
dotnet new install TUnit.Templatesdotnet new TUnit -n "YourProjectName"
A new test project will be created for you with some samples of different test types and tips. When you're ready to get going, delete them and create your own!
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.
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
