Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
`coverage.py` is an amazing library for determining how much of your code is covered by your tests and how much still needs to be tested. Let's look at how to install it, run it, and get handy reports from it.
Installing coverage.py
pip install coverage
Using coverage.py
Make sure you test file can be run from the command line without the -m unittest argument.
coverage run tests.py
Generate a report
coverage report or coverage report -m if you want the missed lines.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[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
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up