Testing coverage of your Django code

Just writing tests for your Django codebase is not enough. You need to check how much of the code is covered in your tests. For this, there are some tools available. Again, it is not just the number of lines of code tested that matters. What matters is “Are these lines important?”. Well, for this, we have to use our head.

covergae is a tool for checking test coverage of python applications. django-test-coverage was built on top of coverage.py to meet requirements of django tests.

I was able to plugin django-test-coverage in Transifex. For some test cases it ran, for others, it failed. It raised a warning saying that a module was being imported more than once. But, the stats generated by it were misleading. Except for files with 0 lines of code (like __init__.py), it showed code coverage % as 0 and 100 only for the files having 0 line of code. I hacked into its code and was able to run it for cases where it had failed previously. But still the statistics were misleading. Time was running out. So, I decided that I would revisit its code some time later.

I resorted to use coverage.py. You can find an introduction about coverage.py at here. Using coverage boils down to 3 steps:

  1. Erase previously collected data : $coverage -e
  2. Execute the necessary tests and collect data: $coverage -x <test module>
  3. Display the result: $coverage -r -m

If the test module is large, the report generated by coverage is also large. I usually save the report to a file : $coverage -r -m > report.txt. Now, I can use grep to shortlist the report to see the details of the files which concerns me now. That’s pretty easy.

coverage.py gives you very useful informations like percentage code coverage of a file, missing statements, etc. Although a higher percentage code coverage is better, but the importance of the lines also matters a lot. You could increase the code coverage by including 10 not so important lines rather than including 1 important line. So, code coverage statistics helps us to write tests to cover more codes, but it is not a replacement to thinking. The final judgement is to be done by us.

Fixing unittests for transifex

Last week, I have been working on fixing the existing unittests for Transifex. The Transifex codebase is constantly being updated. So, some of the previous test cases failed. Before this, I had already written a unittest or two for some of the codes that I contributed to Transifex. But I did not study the Django unittest framework deeply for that.

This time, it was different. I took my time to go through the Django documentation on testing. And then I started to work on fixing the existing tests. To avoid confusion, I ran test on each component separately. Only a few were containing errors like projects, lotte, release, resources, projects, txcommon, suggestions, charts, etc.

I started working on one component at a time. After fixing it, I committed and pushed my changes. Then I proceeded to the next one. In between, I was always in touch with diegobz, kbairak, messas. They helped a lot. I once ran into a bug due to haystack module. I reported this to diegobz. He fixed the issue with haystack quickly.

There was another instance when a particular test was showing errors in my box but not for anyone else. I struggled with it for sometime. Then, kbairak told me that the Transifex code is now compatible with Django-1.2.5, but will become compatible with Django-1.3 soon. And here I was running Django-1.3. kbairak fixed some code to make it compatible with Django-1.3.

The Transifex upstream ROCKS!!!

It feels good to blog again

Well, it has been quite some time since my last blog. The last days of my college, yes, they were very hectic. I had to complete my college project. Well, I had to handle a couple of preventions and seminars, mostly by myself ( although in a group). I finally implemented scatternet formation and routing and built a relay chat kind of thing on top of that. I named it Bluetooth Relay Chat. It worked quite, except for the interface not being that WOW. One can send public messages and private messages as well. I am maintaining the code as a private project in bitbucket. I will release the code soon.

Apart from that, I have been working on Transifex and fixed and improved some stuffs in between. I could not control the urge to contribute even when my exams were near. Apart from that, I have been working on another tool called wordcollections for Ankur Bangla project. It began as a fork of wordgroupz but now is going in a completely new direction.

I was finally happy the day our final semester exams were over. Finally, I can devote my entire day to open source. I stared working on Transifex from the next day. And from June 1, began my internship at Indifex. Currently, I am working on fixing the unittests. I am almost done with the fixing part. Now time to move to write new unittests.