Thanks for the ticket and patch. However, I for one am struggling to
understand why it is so painful to do:
./manage.py test app1 app2 app3 app4
...especially if you create an alias or a shell script wrapper e.g.:
alias foo_project_default_tests=./manage.py test app1 app2 app3 app4
(For myself I've just learnt to use the history features of bash and
that's just as fast [1]).
I also wonder whether this would be an appropriate use of a setting - it
feels more appropriate as command line option for manage.py than a
setting, since settings are things that 'belong' to a project, or to a
project/machine combination, but this is more of a 'developer
preference'. Once you make it a command line option, then I imagine you
are back in the realm of wanting to make an alias/shell script wrapper
so that you don't have to remember it, in which case it's of dubious
usefulness IMO.
Just my 2¢
Luke
[1] http://mike-austin.com/blog/2007/03/history-search-backward.html
--
"The truth will set your teeth free." (Calvin and Hobbes)
Luke Plant || http://lukeplant.me.uk/
It's also not too terribly difficult to write your own test runner that can skip tests based on your particular criteria.
I worked on a project where they altered the db to make User.email unique (using email instead of username for login). This broke many of django's internal tests, but we weren't interested in seeing these results every time buildbot ran the full test suite. So we just wrote a test runner that skipped any app in installed apps that started with 'django.'.
As long as you're willing to trust that Django and the third party apps only release code that passes their own tests , you may want to do this to speed up testing by only testing your own custom application code.
I haven't attempted this with the new class based test runners in 1.2, but from a cursory glance at the docs[1], it looks even simpler than it once was.
Cheers,
John-Scott
[1] http://docs.djangoproject.com/en/1.2/topics/testing/#defining-a-test-runner