Getting a Django Application to 100% Coverage2019-04-30
Code coverage is a simple tool for checking which lines of your application code are run by your test suite. 100% coverage is a laudable goal, as it means every line is run at least once.
I like adding Coverage.py to my Django projects, like fellow Django Software Foundation member Sasha Romijn.
Let’s look at how we can integrate it with a Django project, and how to get that golden 100% (even if it means ignoring some lines).
pip install coverage.
It includes a C extension for speed-up, it’s worth checking that this installs properly - see the installation docs for information.
Then set up a configuration file for your project.
The default file name is
.coveragerc, but since that’s a hidden file I prefer to use the option to store the configuration in
This INI file was originally used only by
setuptools but now many tools have the option to read their configuration from it.
For Coverage.py, we put our settings there in sections prefixed with
The Run Section
This is where we tell Coverage.py what coverage data to gather.
We tell Coverage.py which files to check with the
In a typical Django project this is as easy as specifying the current directory (
source = .) or the app directory (
source = myapp/*).
Add it like so:
coverage: if you’re using
An issue I’ve seen on a Django project is Coverage.py finding Python files from a nested
We can tell coverage to ignore these files by adding
omit = */node_modules/*.
When you come to a fork in the road, take it.
An extra I like to add is branch coverage.
This ensures that your code runs through both the
False paths of each conditional statement.
You can set this up by adding
branch = True in your
As an example, take this code:
With branch coverage off, we can get away with tests that pass in a red widget.
Really, we should be testing with both red and non-red widgets.
Branch coverage enforces this, by counting both paths from the
The Report Section
This is where we tell Coverage.py how to report the coverage data back to us.
I like to add three settings here.
fail_under = 100requires us to reach that sweet 100% goal to pass. If we’re under our target, the report command fails.
show_missing = Trueadds a column to the report with a summary of which lines (and branches) the tests missed. This makes it easy to go from a failure to fixing it, rather than using the HTML report.
skip_covered = Trueavoids outputting file names with 100% coverage. This makes the report a lot shorter, especially if you have a lot of files and are getting to 100% coverage.
Add them like so:
(Again, remove the
coverage: prefix if you’re using
Your Django project probably has a lot of template code. It’s a great idea to test its coverage too. This can help you find blocks or whole template files that the tests didn’t run.
Lucky for us, the primary plugin listed on the Coverage.py plugins page is the Django template plugin.
django_coverage_plugin PyPI page for its installation instructions.
It just needs a
pip install and activation in
If your project is using Git, you’ll want to ignore the files that Coverage.py generates.
GitHub’s default Python
.gitignore already ignores Coverage’s file.
If your project isn’t using this, add these lines in your
Using Coverage in Tests
With Django’s Test Runner
If you’re using
manage.py test, you need to change the way you run it.
You need to wrap it with three coverage commands like so:
99% - looks like I have a little bit of work to do on my test application!
Having to run three commands sucks. That’s three times as many commands as before!
We could wrap the tests with a shell script. You could add a shell script with this code:
However, there’s a more integrated way of achieving this inside Django.
We can override Django’s
test command with a new one that calls Coverage.py’s API.
manage.py test will automatically use coverage.
Create a new
test management command inside one of your Django apps, for example
Then add this code:
A few details:
(1) We’re using Coverage.py’s exclude comment with the
# pragma: no cover comment on
We need to do this since by the time we start coverage, this function has already started.
(2) We need to add
omit in the configuration file, since that also runs before coverage starts.
(It’s fine, and good, to put them on multiple lines. Ignore the furious red from my blog’s syntax highlighter.)
.report() method doesn’t exit for us like the commandline method.
Instead we do our own test on the returned
This means we can remove
fail_under from the
[coverage:report] section in our configuration file.
Run the tests again and you’ll see it in use:
(Okay, it’s still 99%. Spoiler: I’m actually not going to fix that in this post because I’m lazy.)
The plugin will ignore the
[coverage:report] section and
source setting in the configuration, in favour of its own Pytest arguments.
We can set these in our Pytest configuration’s
For example in our
pytest.ini we might have:
(Ignore the angry red from my blog’s syntax highlighter.)
pytest again and you’ll see the coverage report at the end of the Pytest report:
(Yup, still 99%.)
Browsing the Coverage HTML Report
The terminal report is great but it can be hard to join this data back with your code. Looking at uncovered lines requires:
- Remembering the file name and line numbers from the terminal report
- Opening the file in your text editor
- Navigating to those lines
- Repeat for each set of lines in each file
This gets tiring quickly!
Coverage.py has a very useful feature to automate this merging, the HTML report.
coverage run, the coverage data is stored in the
Run this command to generate an HTML report from this file:
This creates a folder called
htmlcov/index.html and you’ll see something like this:
Click on an individual file to see line by line coverage information:
The highlighted red lines are not covered and need work.
Django itself uses this on its Jenkins test server. See the “HTML Coverage Report” on the djangoci.com project django-coverage.
Coverage.py is built-in to this editor, in the “Run <name> with coverage” feature.
This is great for individual development but less so for a team as other developers may not use PyCharm. Also it won’t be automatically run in your tests or your Continuous Integration pipeline.
See more in this Jetbrains feature spotlight blog post.
Is 100% (Branch) Coverage Too Much?
Some advocate for 100% branch coverage on every project. Others are skeptical, and even believe it to be a waste of time.
Like most things, it depends.
First, it depends on your project’s maturity. If you’re writing an MVP and moving fast with few tests, coverage will definitely slow you down. But if your project is supporting anything of value, it’s an investment for quality.
Second, it depends on your tests. If your tests are low quality, Coverage won’t magically improve them. That said, it can be a tool to help you work towards smaller, better targeted tests.
100% coverage certainly does not mean your tests cover all scenarios. Indeed, it’s impossible to cover all scenarios, due to the combinatorial explosion from multiplying branches. (See all-pairs testing for one way of tackling this explosion.)
Third, it depends on your code. Certain types of code are harder to test, for example branches dealing with concurrent conditions.
IF YOU’RE HAVING CONCURRENCY PROBLEMS I FEEL BAD FOR YOU SON
99 AIN’T GOT I BUT PROBLEMS CONCURRENCY ONE
Some tools, such as
unittest.mock, help us reach those hard branches.
However, it might be a lot of work to cover them all, taking time away from other means of verification.
Fourth, it depends on your other tooling. If you have good code review, quality tests, fast deploys, and detailed monitoring, you already have many defences against bugs. Perhaps 100% coverage won’t add much, but normally these areas are all a bit lacking or not possible. For example, if you’re working a solo project, you don’t have code review, so 100% coverage can be a great boon.
To conclude, I think that coverage is a great addition to any project, but it shouldn’t be the only priority.
A pragmatic balance is to set up Coverage for 100% branch coverage, but to be unafraid of adding
# pragma: no cover.
These comments may be ugly, but at least they mark untested sections intentionally.
no cover code crashes in production, you should be less surprised.
Also, review these comments periodically with a simple search. You might learn more and change your mind about how easy it is to test those sections.
Go forth and cover your tests!
Thanks to Aidas Bendoraitis for reviewing this post.
© 2019 All rights reserved.