[SOUND] So, how do you know if you've tested everything in your code base?

Sure, you can look at each line of code and

make sure that there's a test that corresponds to it, but that's tedious.

And then remember, every time you have an if or

an l if, you need to test both branches of it.

Yuck.

Thankfully there's an excellent Python library out there named coverage.py

from Gareth Rees and Ned Batchelder.

This amazing tool handles that line by line and branch by branch checking for

you, and gives you back some amazingly useful information

about where you're missing tests.

Let's go see how to use it.

If you're following along at home,

you'll need to install coverage with pip install coverage.

Before we start using coverage, let's add our if name block to our tests.

So we're gonna go down here.

If name is equal to main

unittest.main.

To use coverage,

we need to be able to run our script directly, I mean it's the easiest way,

there are ways of, of configuring things but this is the easiest way.

So, we're going to leave that in there.

Now, coverage itself is actually just as simple to use as running your test is.

We've been running our test suite with the Python interpreter, you know Python -m.

To run them with coverage, what we want to do, let me clear this,

is we actually just do coverage run, and then our script, so test.py.

And we get the same output that we've always gotten.

We've got the six dots and we've got ran six tests and a few seconds or

a few thousandth of a second and everything's okay.

No failing tests.

We already knew that, because we've got them all to pass in the last video, right?

So, so why use coverage?

This is what it does.

This isn't all it does.

Here's the magic of coverage.

So now we can do coverage report, and look at this.

Now we don't really care about what's here inside tests.

It should always be 100%, but

if it's not we really don't care, because it doesn't matter.

That's our tests.

That's fine.

What does matter though is this line, and we can see that we missed 11 statements.

There are 50 statements total, we missed 11 of them.

And our coverage is at 78%.

78's not bad. That's, that's actually pretty decent.

Now what do we mean by covered?

What's covered, what's uncovered?

Covered is when a line of code in our dice.py has a test that corresponds to it.

And our uncovered code is code that isn't tested, 'kay.

So we know that we're missing 11 lines, but what 11 lines are we missing?

Well, to find that we need to run coverage report and let me give it the -m flag.

M stands for missing.

So if we look at this 13 to 14, 13 and 14, 26, 60,

63, 66, 69, and 72 through 75 are not tested.

So, those are the lines that we care about.

Those are the ones that we want to get covered.

So, let's write a test to cover some more of our module.

Let's look at lines 13 through 14.

So, come back over to dice.py.

Come up here and we look at 13 and 14.

So that's this assertion error, so if we try to make too small of a die.

'Kay, so, let's fix that, that's easy enough to test.

So come back over here to our tests, to our die tests and

let's do def test_bad_sides, because that's what we're doing.

We're making a test that has a bad number of sides.

So with self.assertRaises, and it's gonna raise a value error,

we want to do dice.Die with one side.

Okay, so we know that's gonna fail.

But now we need to run our tests and generate our report again.

So back down here, coverage run tests.py.

Why would six not be found in that range?

Let's try running them again.

Okay.

So seven test, everything's good.

So now we'll do coverage report.

We'll do -m again and now we're up to 82% and

we don't have the 13 or 14 as missing.

Those lines are now covered.

So we still have several lines that are uncovered.

Generally, you want to aim for about 90% or better in your coverage.

But if you look at our dice.py, sorry for jumping around so much here.

A lot of these lines that aren't covered are ones that

are aimed at Python's internals, like this repper line.

Testing these are fine, you can right test for these.

And in fact, you should go right test with them.

Go right test for these yourself.

But you don't have to.

These aren't things that you absolutely have to test.

It's never a bad thing though to hit 100% or better.

I honestly use coverage.py on every single large project I build.

It's saves so much time and trouble figuring out what I've tested and

what I haven't.