TheDarkTrumpet.com

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

First for the site update (and know some stuff is still broken):

1 – I added feeds back to the web site, so RSS is now working correctly. You can add the link here:
http://www.thedarktrumpet.com/feeds/blog/
I will add a link later ont he main site.
2 – I updated my contact form. before it didn’t, work, now it does. I created a project for doing it and it works OK now.

Now for the problems:
1. Update your httpd configuration file. I’ve had the issue where when I uploaded my new code, that my contact form didn’t work. The error message said that it couldn’t find my module – yet it was in my path. What I didn’t realize is that after reading the documentation that you need to be sure to add the parent directory of your modules. So for example, if you use a project directory called sitecode like I do, then be sure to add the directory that contains sitecode as well as sitecode to your PythonPath in your httpd.conf file.
2. If you utilize a separate file for your settings.py (say you use a different database), then ensure that they stay similar and you check this file first. I didn’t, and spent 2 hours installing Python 2.5, modules and all that. I’m not too upset over that, although I really need to roll back to 2.4 on CentOS.

I thought quite a bit about how I can better make sure things work. A solution that’s possible is if you have your project uploaded to your server, then make it “production ready” then run your unit tests. I would have caught #2, but unfortunately #1. I’m kinda curious if the project is uploaded to a sub-domain of a site, and tests run then, and if they pass then put it on full production, if it’d work better. I’m thinking it would – but this is something I did some time ago on my mac, and that’s run CentOS5 with the same general settings as this has. Having a place to push and test to would have probably been a good idea.

Ideas on how you solved this problem would be helpful.