Coverage.py makes it easy to see how much of your code is covered by your test suite. It can be configured to spit out reports in XML (for consumption by a continuous integration server like Jenkins), in HTML (for human viewing), or simply dumping out plain text.
Getting started with coverage and Django is easy. First make sure you have the latest version of coverage (3.5 at time of writing) installed by running pip install -U coverage, then run your test suite and print a report:
This is all well and good, but you’ll quickly notice that coverage reports on every file it touches including third-party libraries, the Django framework, and even Python itself. Often, you only want to see the coverage report for your code. Coverage provides a few options to narrow the scope of the report. They are:
You’ll notice that these take file paths instead of python module names. Running coverage as follows will only report coverage on files in my_project.
This works well, but what if you want to deliver a portable test script including coverage? You won’t always know the path to the project when it is installed on other people’s computers. With a little Python sorcery, we can figure out the filepath at runtime:
How about checking coverage on multiple modules? We can do that too with a small shell script:
A script like this can be bundled with your project so everyone on your team can easily test and see the coverage. Have it output XML and it is ready for use in a continuous integration system (see coverage help and coverage help report for more options).
It’s worth noting that the techniques described here are not Django-specific and can be used with any Python code. Simply replace coverage run manage.py test with your test script, eg. coverage run tests.py.
About the author
Peter is the founder of Lincoln Loop, having built it up from a small freelance operation in 2007 to what it is today. He is constantly learning and is well-versed in many technical disciplines including devops, …