[SOUND] So, how do you know if you've tested everything in your code base? 0:00 Sure, you can look at each line of code and 0:08 make sure that there's a test that corresponds to it, but that's tedious. 0:10 And then remember, every time you have an if or 0:13 an l if, you need to test both branches of it. 0:16 Yuck. 0:19 Thankfully there's an excellent Python library out there named coverage.py 0:20 from Gareth Rees and Ned Batchelder. 0:24 This amazing tool handles that line by line and branch by branch checking for 0:26 you, and gives you back some amazingly useful information 0:30 about where you're missing tests. 0:33 Let's go see how to use it. 0:35 If you're following along at home, 0:36 you'll need to install coverage with pip install coverage. 0:38 Before we start using coverage, let's add our if name block to our tests. 0:41 So we're gonna go down here. 0:48 If name is equal to main 0:50 unittest.main. 0:55 To use coverage, 0:59 we need to be able to run our script directly, I mean it's the easiest way, 1:00 there are ways of, of configuring things but this is the easiest way. 1:04 So, we're going to leave that in there. 1:09 Now, coverage itself is actually just as simple to use as running your test is. 1:10 We've been running our test suite with the Python interpreter, you know Python -m. 1:15 To run them with coverage, what we want to do, let me clear this, 1:20 is we actually just do coverage run, and then our script, so test.py. 1:23 And we get the same output that we've always gotten. 1:30 We've got the six dots and we've got ran six tests and a few seconds or 1:33 a few thousandth of a second and everything's okay. 1:37 No failing tests. 1:40 We already knew that, because we've got them all to pass in the last video, right? 1:41 So, so why use coverage? 1:45 This is what it does. 1:46 This isn't all it does. 1:47 Here's the magic of coverage. 1:49 So now we can do coverage report, and look at this. 1:50 Now we don't really care about what's here inside tests. 1:55 It should always be 100%, but 1:58 if it's not we really don't care, because it doesn't matter. 2:00 That's our tests. 2:02 That's fine. 2:03 What does matter though is this line, and we can see that we missed 11 statements. 2:04 There are 50 statements total, we missed 11 of them. 2:09 And our coverage is at 78%. 2:12 78's not bad. That's, that's actually pretty decent. 2:14 Now what do we mean by covered? 2:17 What's covered, what's uncovered? 2:18 Covered is when a line of code in our dice.py has a test that corresponds to it. 2:20 And our uncovered code is code that isn't tested, 'kay. 2:27 So we know that we're missing 11 lines, but what 11 lines are we missing? 2:32 Well, to find that we need to run coverage report and let me give it the -m flag. 2:36 M stands for missing. 2:43 So if we look at this 13 to 14, 13 and 14, 26, 60, 2:46 63, 66, 69, and 72 through 75 are not tested. 2:51 So, those are the lines that we care about. 2:55 Those are the ones that we want to get covered. 2:57 So, let's write a test to cover some more of our module. 3:00 Let's look at lines 13 through 14. 3:03 So, come back over to dice.py. 3:05 Come up here and we look at 13 and 14. 3:09 So that's this assertion error, so if we try to make too small of a die. 3:11 'Kay, so, let's fix that, that's easy enough to test. 3:17 So come back over here to our tests, to our die tests and 3:20 let's do def test_bad_sides, because that's what we're doing. 3:25 We're making a test that has a bad number of sides. 3:32 So with self.assertRaises, and it's gonna raise a value error, 3:34 we want to do dice.Die with one side. 3:43 Okay, so we know that's gonna fail. 3:48 But now we need to run our tests and generate our report again. 3:51 So back down here, coverage run tests.py. 3:55 Why would six not be found in that range? 3:58 Let's try running them again. 4:03 Okay. 4:05 So seven test, everything's good. 4:06 So now we'll do coverage report. 4:08 We'll do -m again and now we're up to 82% and 4:11 we don't have the 13 or 14 as missing. 4:15 Those lines are now covered. 4:20 So we still have several lines that are uncovered. 4:22 Generally, you want to aim for about 90% or better in your coverage. 4:25 But if you look at our dice.py, sorry for jumping around so much here. 4:30 A lot of these lines that aren't covered are ones that 4:35 are aimed at Python's internals, like this repper line. 4:39 Testing these are fine, you can right test for these. 4:42 And in fact, you should go right test with them. 4:44 Go right test for these yourself. 4:46 But you don't have to. 4:48 These aren't things that you absolutely have to test. 4:49 It's never a bad thing though to hit 100% or better. 4:52 I honestly use coverage.py on every single large project I build. 4:56 It's saves so much time and trouble figuring out what I've tested and 5:00 what I haven't. 5:03