GSoC 2010 Melange Testing Project: Week 7 of the Coding Period

Last week, I found that Python coverage does not track the properties definition of Melange models which makes the coverage of models still quite low. So, I first tried to exclude models from coverage report. This is done by stubbing out nose.plugins.cover.Coverage.wantModuleCoverage with a method which offers the option to skip packages for testing coverage report through pymox stubout. Later, however, I remembered that coverage should be able to track class variables and module variables. I reckoned that the problem may be that these Melange models have been loaded before the coverage starts tracking. So, I further used pymox stubout to stub out nose.plugins.cover.Coverage.begin so that it loads Melange after the testing coverage starts. It works! All the class variables and module variables of Melange models, logic and views can be tracked by coverage and the code coverage now is over 50%.

Then I further worked on various views, e.g. sponsor, program, student, organization, etc and aim to increase the overall code coverage to over 60% next week.

GSoC 2010 Melange Testing Project: Week 3 of the Coding Period

Last week, I finally got Django test client working with the help of Sverre (my mentor). In this week, however, another problem arose. For some urls, e.g. /cron/poke, the response returned by the test client is a Django http response object; for other urls, e.g. /user/show/a_user, however, the response is a dict. After failing to figure out what had caused the problem, I asked Sverre for help again. Sverre suggested that it might be due to the stubout code (pymox) in tests/app/soc/views/models/test_base.py. After I commented the code, however, the problem still did not go away. Later, Sverre found that the problem was due to that the fact that the stubout in tests/app/soc/modules/ghop/views/models/test_task.py has not been unset. So, he added the unset code to tearDown methods and also helped me reviewed/improved and merged my code of refactoring the stubout code into a helper class. Thank you very much, Sverre!

After solving these problems, I started to do view tests for soc.views.models.user using Django test client. I have almost finished it. Yesterday, I pushed the code into my online clone. Today, I asked Sverre to have a quick look to see if it is alright and he was satisfied with it. Though I am still behind my original schedule, I am confident that I can catch up soon. This is because I have solved all major obstructions and have finished adding tests for one logic (base) and one view (user) so that I can follow similar patterns to add tests for other logic and views very quickly.

This week, I also came across the trace module of python when I tried to find another problem I met. It can be used either in command line with python -m option or in your program. This module save you time to code a call back function for sys.settrace by offering some common functions. One useful function is to trace the execution flow of your program. It traces every statement, so be aware the output could be quite large. For example, the output of tracing a single statement of Django test client in Melange testing environment is more than 100MB. Another disadvantage is that the output only shows the module name without package path which could confuse you when you have many modules with the same name or you have a big project and do not know the package of every module. Another useful function is to trace calls. The output of this one is quite small compared with the first function and also has full package path. This function, however, is not perfect either. The problem is that the calling functions are ordered by their module name rather than by their calling order which is arguably more useful. And you have no options to change the order. Besides, you can only use it in command line.