Master The Basics of MSTest Like a PRO In Under 15 minutes!

We all know that if we want to go writing tests in C, we turn directly to XUnit and get started, right? Well, maybe not for much longer because of Microsoft testing platform and MS test. Hi, my name is Nick Oentino and I'm a principal software engineering manager at Microsoft. In this video, I wanted to walk through some of the very basics of working with MS Test and Microsoft testing platform as an alternative to XUnit. And I think this is an important video because if you're like me and you've been writing in C for a long time, you've been probably using XUnit basically your entire life. Or if you're just getting started looking for resources on unit testing and that sort of thing, you're probably seeing everyone talking about XUnit because that's what we've all been using for the large majority of our testing. Now, going forward, we have Microsoft testing platform. They've done a big revamp. I have an intro video that if you haven't watched, you can check it out up here. And I figured that we get started looking at MS test and we'll be comparing and contrasting in future videos with the other testing platforms that we can work with. If that sounds interesting, just a reminder to subscribe to the channel and check out that pin comment for my courses on domain. So let's jump over to Visual Studio and get started. What I have on my screen right now is just a couple of very simple classes and an interface. This is just going to be setting ourselves up for being able to test something. I could come up with a million different examples. I don't want to keep it very complicated. I figured we'd work with something that can take in a dependency. Doesn't really do anything complicated. It formats a string. That way, we can take an input and return a result. So, what you see on the screen right here is really not that important. It's just framing for what we're going to be working with. The important part is going to start with the project structure. So what I have is all of this code which is going to be essentially the code that we're interested in testing. We have that in one project that we can see in the left nav here. So system under test project is where all of this stuff is dumped into. It's a little console application. So if we wanted to go run this, yes, it will just go make the dependency, make the system under test, and then call the format welcome message method. not complex, very simple, kind of weird, kind of boring, but I'm not really amazing at coming up with great examples. So, we have this to work with. We have this test project that we're going to look at as well, and that's going to be this second project down here. This is going to be where we're spending most of our time. So, let's jump over to see what we have inside for dependencies and how this project is set up. The first thing that I want to call out is that we do need to have a reference to the other project. If you're brand new to testing inside of C, generally how we create tests is that we'll have an assembly. So a project that creates an executable or a DL. We have that project and then we have our test project. So that's why there's two. We have our test project depend on that other one. And that's because the test project needs to see the things that we want to test. And then you might say, well Nick, why do we need two projects? Why not jam the test in the first one? And the main reason for that is that if we're thinking about code that we're shipping, generally we want to have our tests separated from the code that gets shipped. Usually that's why you see test projects separated from the code that you're probably shipping, deploying, and running. That's what this project references down here. But the other part up top is where things get interesting. So I'm going to be using MS test. You can see at the time of recording the version is 3.8.3. So I have that referenced here. And if we look, it's going to be an executable output type, which if you have some experience writing tests with XUnit and some other things, usually we see that we have a DLL that's being output. This is going to be an executable. And then the other thing to note is that if you're following along and you wanted to use this as a tutorial, if you just go and add a new project, generally you'll see that your type at the top here is not the exact same. So, this does say SDK msest. SDK. And then you'll notice the version up here maps to what I have down here. And that's just again another reminder that if you're on a different version and you're just sort of blindly copying what you see on the screen, make sure this version matches what's up top. We do need to change this. Right? This is not how it came standard. I had to go copy and paste this line over and make sure that I have MSET. SDK slash and then the version number. So the pieces that we need to make this work are going to be this project dependency. Then we have the Nougat package reference which is going to be MS test. You can use the latest version if that works for you. I'm on 3.8.3. And then we change the project to have an SDK attribute of MS test. SDK. I'm making this output type executable. And that's so that we can go and run this, which is a bit different behavior than we're probably used to when we're running tests. That's one of the interesting things that we'll get to in just a moment. These are the things that you need in your project. I'm going to jump over to some code and then we can see how we can start using this. Jumping over to the test CS file. If you're new to working with MS test, it's like other testing frameworks where we generally add some decorations onto our classes and methods that are going to be used for testing. When I talk about decorations, we call them attributes in C. We can see that we have a test class up top. So, we're just annotating the test class called test with test class. It's going to probably get a little bit weird because the word test is probably going to be said a million times or so. So test class attribute on our tests class. That's a mouthful to say. You'll also notice that I have two methods in here. These are just two different tests. They technically test roughly the same thing. I just wanted to be able to walk through a normal test method which is up top here and then a parameterized test method. But before we continue on, this is just a quick reminder that I do have courses available on dome train. If you're just getting started in your programming journey and you want to learn C, you can head over to dome train. I have a getting started in C course. It's approximately 5 hours of content taking you from absolutely no experience to being able to program in C. And after that, I have my deep dive course which will take you to the next level with another 6 hours of content so that you can start building basic applications. Head over to do train and check it out. Let's head back to the video. If you are used to XUnit and I have other videos on this and I will create more. In XUnit we call a test method a fact and in XUnit we call a parameterized test a theory. So in MS test it's just test method and data test method respectively. Let's collapse the bottom one. We're just going to look at the very basics of what's going on up top here. You can choose to name your test however you'd like. It's not going to be important for this video, but you can see that I'm making the dependency. I am making the system under test. Then we're going to call format welcome message. Right? So this code is the exact same as what you'd see over here. I just wanted to be able to set this thing up. Call format welcome message. Then what we're going to be able to do is call an assert. So we want to assert the behavior of this system under test. That's why we're writing tests. So we can use assert.re are equal and then we have the message that we expect. The convention for this is generally that the first parameter is what you expect and the second parameter is the actual result. These are just very basic testing things in this video. We're keeping it very simple. I'll have more follow-ups, more details and if you have questions that you specifically want to see answered, you can always ask in the comments and I'll follow up. We have this as a very simple test. Okay, so test method and assert at the bottom and then the system under test being created and called right before the assert. If we go to the bottom one, we can see that it's almost the exact same thing, right? The code, if you squint your eyes and blur your vision, the code looks almost identical inside of here, right? But the difference is that we parameterized it. And what that means is that you'll notice we have an input and expected and then we have these extra data rows up top. What that means is that we're going to keep the body of the test the same. We're going to have three different tests. The body of the test is the same, but we're going to be changing the input because we have a different output that we expect for that input. It is functionally very similar to the test that we just talked about in terms of what it's doing, but it's essentially going to run three different tests because we've parameterized it. So hopefully that makes sense. Like I said in XUnit, if you're familiar with that, it's going to be fact for single test and theory for parameterized tests. At this point in time though, what we're able to do is we can go run these tests. And the traditional way that we do this is that we would go over to our test explorer. I have mine in the far right here. And then if I want to, I can go ahead and press this button that's run all tests in view. But I just wanted to show you that on my screen, if I click through, you can see that I have these two test methods. Yes, the one test that is parameterized is technically multiple tests, but when we're viewing it before it's run, we don't see all of the data rows kind of called out as separate tests. And you'll also notice that it's broken out by the assembly, the name space, then the class, and then the test names as well. Let's go ahead and run these. Nice and simple. And there we go. Oh, you'll also notice that once I've done that, you see this little arrow popped up on the last one. Now, I actually do see that there are multiple tests inside there, right? There are three different tests. If I go through them each, you can see the parameters changing as I scroll. Right? So, you can see all three tests get run and this one up top as well to give us four in total because there's three here and one up top. So, a total of four tests. One more quick note before I show you one more feature is that data test method and test method they actually have a display name. So if you wanted to you could give them a different name whatever you wanted to do. So you could have this naming convention for in your code but if you wanted to have spaces just as an example you could do anything you want. I'm just showing you that. There you go. Right, you can't have spaces in the actual name in the code, but you could do it in the display name if you so chose to do that. That is going to be the very basics of setting up tests with an assertion. But there's one more thing that I wanted to show you and one other thing that I wanted to call out, especially if you're used to using other testing frameworks with XUnit. The way that we would need to go ahead and do this is that if I jump back into the project, we would have a different reference here because it's not ms test. It would have been xunit. But we would also have to go include some other packages to make sure that we had a runner. And we don't have to do that anymore. So what I showed you when I pulled out the test explorer when you're using xunit, it doesn't just give you that out of the box historically. And that's not really a deal breakaker, but it's kind of weird cuz you add xunit and you're like, "Okay, I wrote the test, but they don't show up. You have to add the runner so that it shows up in Visual Studio." We just get that for free with MS test. And when we're working with Microsoft testing platform and I just wanted to show you this little feature up at the top that I mentioned earlier that this test project is an executable. And that means if you've noticed in the bottom of my screen this whole time we can do net run the project name and just give it the name of the test project. I don't even need to have a testr runner. I don't need to do net test. I don't need the test explorer. I can do this. I can press enter and there we go. Just by running the project, it actually knows based on the SDK type of the project that it is going to be a test project. So, it goes ahead and runs them. And I think that this is super cool because everything that you need to be able to test is just included in your executable that you've created. This is a little bit of a departure from what we're used to with something like XUnit. Historically, probably most of the other things that we looked through were very familiar maybe with just some different names. But I think that this is a really cool piece of functionality because especially if you're trying to set up continuous integration, continuous deployment and having pipelines and things set up, you just need to go run your executable now and it's going to do your test for you. So, I think that's pretty cool. And this is just an intro and highlighting some of the reasons why I'm kind of interested in moving over from XUnit to MS test with Microsoft testing platform. I hope you found that helpful and when the next videos are ready, you can watch them up here to see more about testing. Thanks and I'll see you next time.