xUnit VS Shouldly

Attachments: At this time you still cannot attach files to test runs, although the functionality finally is coming in V3!

I was trying to think of an example of where C# attributes might be used in every day life and then it dawned on me: unit testing! If you have ever used a unit test framework such as MSTest, NUnit or xUnit, you will have used attributes in C# to define the classes and methods that you would like the test framework to execute. This is just one example of how you can use attributes to assign metadata to elements of your code.

Because I struggled with the initial tests written using MSTest, I converted all the tests to xUnit – some of this was out of sheer comfort with xUnit over MSTest, but also because its OSS product under the .NET Foundation – and I like supporting those.

I didn't want to create "yet another test runner," but I couldn't get any of the existing ones to do everything I needed. It's fairly well known that you can't run or debug xunit tests in a Godot game unless you're using Rider, and since I'm a die-hard VSCode user, I didn't want to make the switch. XUnit also runs tests in parallel by default, which isn't usually what I want in a game-like environment, so it just felt like a poor fit overall.

The setup here is really minimal, just create a new test project. I'll be using xUnit but NUnit should be fine too.

xUnit

If you're using xUnit for your tests, you can implement the IAsyncLifetime interface it helpfully provides for you.

The projects are all .NET 6 applications with nullable references types and implicit usings enabled. The unit testing projects use Xunit out of the box. There are also support files such as .gitignore, .editorconfig, etc.

The testing framework that I chose is XUnit. The first reason is that it is trendy compared to another test framework such as NUnits. I created test methods stub from the existing code by Create Unit Tests command. To use it with Xunit, I have to implement the XUnit.net.TestGenerator extension to my project.

On a side note, something I would highly recommend NOT doing is using the built in assertion types for any of the test adapters. Without a doubt the hardest part of switching unit test frameworks is having to fix all your assertions which is why we use 3rd party assertions. The built-in assertions also tend to not be very feature rich and don't have the most helpful messages. We personally use FluentAssertions, but there are other options such as Shoudly or Should. I highly recommend picking one of them over the built in assertions. You will thank yourself later :)

Shouldly - More "fluent" way of writing assertions that I tend to like more personally. Example:

I use NUnit and Shoudly.