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. You may have experienced these, or you may have not even known and experienced flakiness or bugs due to it.

NUnit by default creates 1 test class for all the tests within it, and runs them all against the same instance. Therefore if a test stores or accesses any state, it could be a hangover from another test, meaning leaky test states and potentially dodgy data.

xUnit doesn't offer a way out-of-the-box to retrieve the test state within a hook. For example, running UI tests, in a tear down method, you might want to take a screenshot but only if the test failed. The hook is written generically to work with every test, but we don't have anything available to us to query for the test status.

xUnit performs tear downs through interfaces such as IDisposable. TUnit also allows this, but a problem occurs if you want to use test class inheritance. Say you have a class that wants to take a screenshot, and then a base class that disposes the browser. You have to declare another Dispose() method, and hide the visibility of the base one with the new keyword, which is generally frowned up. You then also have to remember to call base.Dispose() - and if you don't, you may have bugs and/or unreleased resources. And then to top it off, you have to manage exceptions yourself to ensure they still run. In TUnit, all cleanup methods will run, even if previous code has encountered exceptions.

xUnit assertions are fairly basic and have the problem of it being unclear which argument goes in which position:

NUnit assertions largely influenced the way that TUnit assertions work. However, NUnit assertions do not have compile time checks. I could check if a string is negative (NUnitAssert.That("String", Is.Negative);) or if a boolean throws an exception (NUnitAssert.That(true, Throws.ArgumentException);). These assertions don't make sense. There are analyzers to help catch these - But they will compile if these analyzers aren't run. TUnit assertions are built with the type system in mind. Specific assertions are built via extensions to the relevant types, and not in a generic sense that could apply to anything. That means when you're using intellisense to see what methods you have available, you should only see assertions that are relevant for your type. This makes it harder to make mistakes, and decreases your feedback loop time.

Extras

TUnit offers a few extra bits that NUnit and xUnit do not (that I'm aware of):

• Tests are source generated - And not relied upon using reflection to discover them
• Hooks are available at the assembly, class and test level, each with respective objects available to be referenced in your hook methods. An AssemblyHookContext object will have details on the current assembly and a collection of all the tests its discovered. If you're in a tear down, each test object will have details of its result. A ClassHookContext is the same, but with details of the class and its tests instead. And a TestContext will just be the details for a single test.
• Dependent tests - Tests can depend on another and delay their execution until their dependencies have finished - Without turning off parallelism or having to manually work out the best way to configure this.