Running Tests4:19 with Jeremy McLain
We can run our tests right within Visual Studio.
One thing we didn't do. 0:00 Is run our test to see if it passes or fails. 0:01 We can run our tests right from within Visual Studio. 0:04 There are lots of ways to tell Visual Studio to run the tests. 0:07 If we want to run all of our tests. 0:10 We can click on the Test menu up here. 0:12 And click Run all Tests. 0:14 When the tests have finished running. 0:19 The Test Explorer pane here opens up. 0:21 If you don't see the Test Explorer pane. 0:24 You can open it by clicking on Test > Windows. 0:26 And then Test Explorer. 0:29 Here we see a list of all the tests we have so far. 0:32 PointTest passed but DistanceToTest failed. 0:36 This is because we haven't coded it yet. 0:41 Let's do that now. 0:43 Let's instantiate a point to calculate the distance to. 0:48 So I'll say var point = new Point. 0:51 And we'll make it 3, 4. 0:55 Now we need to create the point object that we want to test. 0:59 But we'll need a name for this object. 1:02 We already used point. 1:04 We could call it something like starting point. 1:06 But I like to use a convention in order to keep my test readable. 1:09 I'll name it target. 1:13 I name it target because this is the instance of the class we're testing. 1:17 Other testers may call this something else. 1:20 Such as System Under Test. 1:22 Or SUT for short. 1:24 I've seen other developers name it Class Under Test or CUT. 1:26 Personally, I prefer target. 1:31 So I name all of the objects that I'm testing target. 1:32 Let's make target the point 0, 0. 1:36 Now let's call the DistanceTo method. 1:42 And store the result. 1:44 I store the result of a method I'm testing. 1:45 In a variable named actual. 1:47 Because this is the actual output. 1:49 We'll need to compare what we actually got. 1:52 With what we expected. 1:54 So let's store our expectation in a variable named expected. 1:56 From 00 to 34. 2:00 We should expect a distance of 5. 2:03 Or more precisely 5.0. 2:06 Since DistanceTo returns a double. 2:09 Now we need to assert that what we expected. 2:12 Is actually what we got. 2:15 Again we'll call Assert.Equal. 2:16 We'll say expected, actual. 2:21 Only this time we need to be careful. 2:25 Because we're comparing doubles. 2:27 Comparing two doubles can have unexpected results. 2:30 To demonstrate what I mean. 2:33 I'll open up the C# REPL built into Visual Studio. 2:35 It's called the C# Interactive Window. 2:38 You can find it by going into View. 2:41 Down to Other Windows. 2:43 And then clicking on C# Interactive. 2:45 Let's see what happens when we add 2:49 1.1 to 2.2 This should equal 3.3 right? 2:54 Let's check. 3:02 We would have expected true. 3:08 But we've got false. 3:10 What's going on here? 3:12 Let's subtract one from the other. 3:14 What we get is a very small number. 3:18 This is equivalent to 0. 3:21 Followed by 16 decimal places. 3:23 With 4 in the 16th decimal place. 3:26 Not what you would expect, right? 3:30 Doubles are floating point numbers. 3:32 Which means they have limits on how precise they can be. 3:35 Certain decimal numbers. 3:38 Are not always able to be accurately stored. 3:40 In a floating point type. 3:42 The larger the number the least precise they are. 3:45 15 points of precision is pretty good. 3:48 When adding these two numbers. 3:51 Most of the time this isn't an issue. 3:53 Except when comparing floating point numbers. 3:55 Luckily, unit test frameworks make comparing doubles easily. 3:58 When comparing doubles using Assert.Equal. 4:02 We can use a third parameter to set the precision that we expect. 4:05 In this particular case, we'd expect to have at least one point of precision. 4:09 For good measure, I'll make it two. 4:14 This test method is now complete. 4:17
You need to sign up for Treehouse in order to download course files.Sign up