One more comment after a day of writing unit tests: installing coverage.py via a test runner is not a good idea.
The test runner is executed pretty late and there is a chance that part of your code gets executed earlier. I do not know if this is the only possible case, but I had the code in appname/__init__.py files executed during translation initialization, which is way before Django even looks at the command line passed to manage.py. Right now my code detects the --with-coverage option and installs coverage right in projectname/manage.py as the very first thing, before importing any other module. This gives far more accurate results. I still believe it would be a good idea to add the --with-coverage option to Django, since it would make it a bit easier it for people to do proper testing (and one less excuse not to do it right). If it sounds good to you I can create a patch for that, moving the code that installs coverage.py to django.core.management. -mk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
