Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Our First Test6:31 with Jeremy McLain
Let's start writing some tests!
[MUSIC] 0:00 Let's write some unit tests for the point class. 0:04 To do this we'll need to create a project to store our unit tests. 0:07 Unit tests are contained in their own assembly, so 0:12 that they're separate from the code of the application, or library that they test. 0:14 This allows us to distribute or publish the application, 0:19 without shipping the unit test with it. 0:22 There are a number of ways we can create this project. 0:24 The easiest is to use the extension we just installed. 0:27 Using this extension we can have Visual Studio generate the project and 0:31 have it create the scaffold code for testing the point class for us. 0:35 We just right-click on the name of the class and click Create Unit Test. 0:39 Make sure that the correct unit test framework is selected here. 0:47 Because we previously installed xUnit.net test extensions. 0:51 We can select xUnit.net. 0:54 If we already had a unit test project set up. 0:56 We could select it here. 0:59 Instead, we'll keep this set to new test project. 1:01 We can specify the names for 1:05 the project, namespace, output file and test methods here. 1:06 We'll keep the defaults as there are fairly standard ways to name these. 1:12 Organizations or teams may have their own naming conventions, 1:15 in that case you want to change these to match your teams. 1:19 Finally we pick what we want to start out with in the test method body. 1:22 I like to have them assert failure, we'll see what this means in a bit. 1:26 Click on OK to have Visual Studio generate the unit test project and the scaffold for 1:31 our unit tests for us. 1:36 Let's take a look at what it generated. 1:38 We now have another project in the solution named TreehouseDefense.Tests. 1:41 This is our unit test project. 1:46 The extension created the project and 1:48 installed all the NuGet packages that are needed. 1:50 Let's take a quick look at these packages. 1:53 Just right click on the project and then click Managed NuGet packages. 1:55 Here we see the NuGet packages that are needed for xUnit to work. 2:01 This final one here is a test runner. 2:04 Visual Studio uses this package to execute tests and get the results. 2:07 There's also a console version of this package which can be used to execute 2:12 tests from the console. 2:15 Which is handy for 2:17 when we don't want to have Visual Studio open in order to run our tests. 2:18 It can be installed as a separate NuGet package. 2:22 We didn't need to use the extension to set up our test project. 2:25 The test project is just a C# class library. 2:29 We could have created the project and 2:32 downloaded the individual NuGet packages ourselves. 2:34 I just find using the extension a lot more convenient. 2:37 Inside the project that was generated, we have one file called point test. 2:41 It contains the test class for the point class. 2:46 A test method was created for each public method in the point class. 2:49 This is where we write our test. 2:54 Notice that above each test method there's an attribute named fact. 2:57 You may not be familiar with attributes in C#. 3:01 Attributes allow us to annotate the code with additional information. 3:04 This information can be used by the compiler at runtime 3:09 using a feature of .Net called reflection. 3:12 In this case the attribute is used to tell the unit test runner that this method 3:15 is a test method. 3:19 MS test and N unit also use attributess to denote a test. 3:20 MS tests names this attribute test method. 3:25 And N unit simply names it test. 3:28 But all three have the same effect. 3:30 You can pass parameters to attributes, but we don't need to right now. 3:32 Parentheses are optional if there are no parameters. 3:35 Now our task is to write unit test cases for the point class. 3:39 Let's start by testing that the constructor of the point class is 3:43 coded correctly. 3:46 We'll put this code in the first method named point test. 3:47 When writing unit test, 3:51 we follow a very simple pattern which is arrange, act, assert. 3:52 First, we prepare to perform an operation by arranging our data. 3:57 If we look at the point constructor, we'll see that it takes two parameters. 4:02 We have x and y. 4:07 In our test we'll need to decide what will pass the constructor. 4:09 So I'll say int x = 5 and int y = 6. 4:14 Now we need to execute the operation. 4:23 This is the act part of the pattern. 4:26 In this case we'll construct a point with these parameters. 4:28 So I'll say var point = new Point and pass in x and y. 4:31 Now, we need to verify that the x and 4:40 y fields in the point object were set correctly. 4:42 This is called an assertion. 4:45 Because we are asserting that something is the way we expected to be. 4:47 If the assertion fails, the test fails. 4:51 Here we already have an assertion but 4:54 we'll need to change it to something that makes sense for this test. 4:56 So I'll say Assert.Equal(x), which is what we expect, 4:59 and point.X, which is what was actually set. 5:06 We'll also check Y. 5:12 So there you go. 5:18 There's the test. 5:20 When this test passes, we can be sure that the fields of the class 5:21 are initiated to the correct set of values when it's instantiated. 5:25 You may be thinking this was a pretty dumb thing to test. 5:28 And yes, a lot of unit tests, test dumb things like this. 5:32 But a bunch of little dumb tests add up to ensuring that we have high quality 5:36 software and peace of mind. 5:40 Let's say when I was coding the point class, 5:42 that I did something like this in the constructor. 5:44 It was an honest mistake. 5:51 X and Y are really common variable names. 5:53 Especially when coding for 2D graphics. 5:56 In reality, I get x and y mixed up all the time. 5:59 Seriously, I mean all the time. 6:03 And before I was religious about writing unit tests, I often wouldn't discover 6:05 what I did until things started moving across the screen in the wrong direction. 6:10 Then, I'd have to go track down where I went wrong. 6:14 This meant inspecting all of the hundreds of x and y's in the program. 6:18 It's enough to make someone go insane. 6:22 I'm not kidding. 6:24 Writing a dumb little test method like the one we just wrote 6:25 is well worth the peace of mind that it brings. 6:28
You need to sign up for Treehouse in order to download course files.Sign up