Code coverage for your unit tests
Writing tests for your django application is an absolute must in my opinion. When one writes tests, you can detect problems much faster when you change something, or if something happens in the code base. I’m a fan of keeping up with the most up to date version of django, and more than once my unit and functional tests saved my tail. I covered more about how to write unit and functional tests here:
http://www.thedarktrumpet.com/blog/10/ so I won’t go into it more at this point.
What I want to cover is something else I find important, and that’s code coverage. The problem arises is that basically we are all human – and there may be some “little areas” of our application that are untested. A real life example of this came today for myself. I checked one of my applications with trace2html, and found that I had 88% code coverage in one of my models. Sounds like a lot right? Really that’s not, when looking at the details I found out that methods were totally overlooked in testing. Keep in mind that much of a django model are the properties related to your schema, and that information is counted as being tested (at least it did for me, perhaps that’s because I unit test the creation of records, and functional test the same stuff). 88% code coverage in this model counted all the properties, but I missed the methods – the very things I should ensure to test.
Another blog entry I read recently discussed the same problem, and he came up with a different solution. His post is here:http://eddymulyono.livejournal.com/62101.html, but I disagree with his solution. His solution entailed changing the core code to add in the code coverage section. This is very problematic for upgrading, and – I’m just not a fan of changing core code unless something is broken and submitting a patch.
With that in mind, trace2html is what I went with.
You can get the module first from here:
http://pypi.python.org/pypi/trace2html/
To run your test, you simply run it like this:
trace2html.py –run-command manage.py test
Your tests will take a good 20-30x longer, and you’re probably going to receive a number of errors related to the core libraries. I found this not really a problem because I wanted the information specific to my own directory (which -W I couldn’t get working in this instance). After the test finishes, just launch firefox:
firefox coverage_dir/index.html
Much of what you see there can really be ignored. What you’re going to want to pay attention to are the apps that you have at the top of the listing. Most of them should be in the high percentage, even if you don’t do any unit testing (again, keep in mind that much of a model is property data). You can click on each of those links to see where the coverage is lacking.
In my opinion, you should probably reach 100% code coverage on your tests. This isn’t the general rule of thumb from other people I heard – who recommend 80%, but given the already high percentage, getting to 100% shouldn’t be too difficult. This will also test out your views as well (which should be covered by functional tests).
I feel this is worthwhile to run in all your projects. Running every so often, say every few months just to “step back and take a breath” will help keep your code well tested. Good tested code means happy code 
