Beginner's Guide For Writing TUnit Tests In C#

This is going to be a quick video on getting started with TUnit, which is an alternative testing framework to things like XUnit or NUnit that we might be more familiar with. Hi, my name is Nick Cosantino and I'm a principal software engineering manager at Microsoft. This video is an entry into the testing playlist that I'm putting together focused on the Microsoft testing platform. And if you haven't watched the previous video already on TUnit, I'll link it right up here and you can go check that out for some background in case you haven't heard much about it yet. Now, in this video, like I mentioned, we're going to go through the basics. I'm just going to show you how to get it set up, do some sample tests, and that way you're at least enabled to get up and running. So, if that sounds interesting, just a reminder, subscribe to the channel and check out that pin comment for my courses on domain. Let's jump over to Visual Studio and get set up. To kick things off, like I will be showing in all of the videos in this series, I basically just have this uh system under test project. So, you can see in my solution explorer, I just have it here. It's not really important, but just to have something that we can go call from the test. I just have this really simple class with an interface and stuff set up. So that way we have something basic to go work with. Now, I did cover XUnit before. I did do a little bit of background on TUnit and I figured that I'll show you how we can get TUnit added. So you can see that in terms of the package references, I just have TUNT included here. At the time of recording, it's version 0.2521. 2521 for me. We do need to pay attention up here that I have the output type as an executable. And this is important to note because historically, right, if you're a .NET developer, a C# developer for many years now, you you know that if you're building things in XUnit and other tests like you make a class library, right? That's the thing you make. Then you have your test framework, your test harness, the runner, it's going to go use those libraries and execute those tests. But with Microsoft testing platform, one of the things that we get is this ability to have these self-contained test executables as well, which is super cool. So, we want to make sure the output type is an executable. I will show you in this video that we can still run them in the test explorer in Visual Studio and we can run them on the command line as well. So, do pay attention that you want this executable type up here. I am using .NET 9 at the time of recording. if you're watching this in the future. We might be on 10, 11, who knows by the time you're watching this, right? And then, like I said, the package reference is the thing you'll need. Uh, also pay attention. This is of course going to be different in your test setup, but I need to reference the project that has the system under test. In my case, it's the one that I was already showing you, this super long line here, because I was really verbose with my naming, but you'll want to make sure that you have that dependency included. If you're brand new to this and you're not sure how to do all of these things, right, you're going to want to click on your project. You can add this output type as executable in order to get TUnit added. You can either do it on the command line or if you're not comfortable with that, you can rightclick on your project, go to manage nougat packages, and then if you go to the browse tab, you can just search for TUnit, right? And then I have it right here. You can see it's by Tom Hurst. and then you can go uh install it. For me, there's an uninstall button. Now, if we go back and you're like, "Okay, well, how do I reference my other project?" Simply rightclick on the dependencies in the solution explorer, add project reference, and then you can pick the one that has your system under test that you want to be testing. So, that should get you up and running to get to this point, which is now where I'll show you. I have this test.cs file. And I want to show you that if I go open up the same one from XUnit, watch how much change is on my screen, basically nothing, right? Using XUnit at the top versus not. And then I have a different name space, right? The actual tests are basically identical. We have a couple of small differences though just in terms of the syntax. So this is the XUnit one. I think most people if you're coming from, you know, previous experience in C and net development. Most of us are very familiar with XUnit. It's one of the most popular frameworks for testing and we have a fact that is a single test and a theory that is a parameterized test. This is basically like three tests in one. If I go back to Tunit, we have similar things going on though, right? So, this is a single test. They were very creative with their attribute naming. It's just called test, which I think is it's a little thing, but I think it is really good because it's always funny when I'm making videos on XUnit and I'm saying fact and theory like it's just a test, man. Just call it a test. Makes it way easier to communicate to newer developers. So, they use test as the attribute. And even when it's parameterized, it's still just test, which again, small detail. I do actually really like that though. Now you'll notice on TUnit we have arguments here, right? So this is the same as inline data. If I jump over to XUnit, you can see inline data here. And I'm going to go back to TUNT again. It's just called arguments. And the way that this works, like I said, it's a parameterized test. So the first value is going to go into the input parameter and the second value is going to go into the second parameter of the method. So that one's going to be so input and then expected. Pretty straightforward. And basically, if you're familiar with XUnit, it's almost identical in terms of how this works, just different naming convention. There are different sets of features that we have in TUnit and XUnit. And at this point, I'm going to invite you in the comments if you want to see different features that are either compared or different examples of working through T-Unit features, please just leave a comment below. I'm happy to go make a video and do a deeper dive, but this one's just a super highle way to get you up and running. Okay, so let me know in the comments if you want more specific things covered. The other final thing that I'll call out in terms of the code that we have is just a brief comparison on the assertions. We do have in TUNT they have a fluent sort of assertion syntax but this is just the simple like assert equals. If I go back to XUnit assert equal, right? Almost identical. We just have an S instead in this case. pay attention to the different assertion types, but they do have asynchronous assertions as well as async fluent assertions where you can start chaining them together. If you're not sure what I mean by fluent, if you're familiar with link where you can chain things together, that's sort of like a fluent syntax. That's all for the code. Like I said, very high level, but I want to show you on the test explorer and on the command line. So, we see here that I have my test showing up. I'm going to go ahead and I can rightclick and say run the TUnit tests. Boom. They finish. The XUnit ones are here. In the previous video when I was going over the TUnit features from their GitHub page, one of the things that they called out was that it was, you know, like performance optimized. And I'm not disagreeing with them. I just wanted to show you because I mentioned it in the other video that for some reason when I run these here like I have XUnit being faster basically every time by an order of magnitude. Now we only have four tests. They're super trivial. I'm not doing anything fancy in terms of the T-unit setup. I think some of their benchmarks were showing that if you're using AOT and trimming then that's where you start to get the benefits. But overall it's still really fast. But I was just actually really impressed that XUnit was even that much faster. So anyway, I would probably encourage people to pick testing frameworks that number one they are comfortable using. Number two, you know, they work in your team or your development environment and have the features that you're interested in. In terms of the performance and the testing frameworks, I find that if you're going to compare nunit, xunit, tunit, ms test, my opinion on this personally is that the performance driver is probably not the big deal from the testing framework. It's a lot more likely that the way that you're setting up your test is going to be the thing that saves you time. So I'm only calling this out in this video because I mentioned it in the other one and I thought that it was very interesting that you know even in this simple setup it's an order of magnitude different. Now final thing that I'm going to call out is if we go to developer powershell in the bottom here you can see that I am in the tunit directory for my project. If I do net run because it's an executable I can actually just run this and it's going to have the output from the test. So if I make that a little bigger, you can see they got some awesome ASI art. I love ASI art. It's super cool. You can see um has Microsoft testing platform right in here. So this is just going and running the executable for us, right? It's running the tests. If we compared to the other video with XUnit, it was a similar thing where you could either use the XUnit runner or the Microsoft testing platform runner and basically you get this uh you know stylized output for your test. So this kind of thing I think is super handy when it comes to CI/CD. You're running things in a pipeline. If you're used to this historically, you need to make sure you have your dependencies set up and that kind of stuff. But now it's really just a matter of like is your executable there to go run. I think that's kind of handy. So, overall, pretty lightweight, super quick to get set up and a very familiar, at least in my opinion, set up to things like XUnit that we're very used to, just slightly different naming conventions overall. That's going to be it for TUNIT. Hopefully, you can get up and running with that in short order. And like I said a little bit earlier, if there's other features that you would like to see in Tunit, just call them out in the comments. say uh what things that you're interested in maybe for having different challenges or you want to explore a feature, let me know. I'm happy to go spend some time and put a video together for you. So, thanks for watching and I'll see you in the next one.