On 9/1/06, Adrian Holovaty <[EMAIL PROTECTED]
> wrote:
I agree that a command line argument would probably be viable if the problem was restricted to just runtests.py, but it struck me as an example of a bigger problem.
In Michael's case, it sounds like test_myapplication would never be a viable database name (due to some name clash). Given that he knows this, and it will be a persistent condition, asking him to type './manage.py --test_db_name="no_clash_db_name" test' every time he runs his test suite seems a little onerous. He isn't expected to do the same for DATABASE_NAME - a setting lets him configure his preferred name permanently on a per-app basis.
I suspect most users will never need the setting - the default naming policy should be enough. However, the same could be said for other settings, too (e.g., EMAIL_SUBJECT_PREFIX)
As a bonus, the TEST_DATABASE_NAME setting provides a clean mechanism to avoid running the Django system tests in an application's test database.
Does that sound reasonable?
On a related, cross thread note: any comment on the test system signaling benchmarks and the solutions proposed?
Yours,
Russ Magee %-)
Any particular reason you used a setting instead of a simple
command-line parameter? In my view, we should only be adding settings
if absolutely necessary.
I agree that a command line argument would probably be viable if the problem was restricted to just runtests.py, but it struck me as an example of a bigger problem.
In Michael's case, it sounds like test_myapplication would never be a viable database name (due to some name clash). Given that he knows this, and it will be a persistent condition, asking him to type './manage.py --test_db_name="no_clash_db_name" test' every time he runs his test suite seems a little onerous. He isn't expected to do the same for DATABASE_NAME - a setting lets him configure his preferred name permanently on a per-app basis.
I suspect most users will never need the setting - the default naming policy should be enough. However, the same could be said for other settings, too (e.g., EMAIL_SUBJECT_PREFIX)
As a bonus, the TEST_DATABASE_NAME setting provides a clean mechanism to avoid running the Django system tests in an application's test database.
Does that sound reasonable?
On a related, cross thread note: any comment on the test system signaling benchmarks and the solutions proposed?
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@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-developers
-~----------~----~----~----~------~----~------~--~---
