On Jan 20, 2008 2:13 PM, Jim Crossley <[EMAIL PROTECTED]> wrote: > > "James Bennett" <[EMAIL PROTECTED]> writes: > > > On Jan 19, 2008 10:24 PM, Jim Crossley <[EMAIL PROTECTED]> wrote: > >> Yes, I knew I could override the NAME, but I'd like to override the > >> ENGINE,USER,PASSWORD,HOST, and PORT, too. Our settings are configured > >> for mysql/innodb, to match our production environment. But as our > >> test suite and initial_data grows, it takes a frustratingly long time > >> to run the tests. I'd like to use the faster sqlite, but just for the > >> tests. Can you suggest an approach? > > > > Yes. Create another settings file, and in it put the following: > > > > from your_real_settings import * > > > > DATABASE_ENGINE = 'sqlite3' > > DATABASE_HOST = '/some/filename/' > > So then I assume I must do something like this to run my tests? > > DJANGO_SETTINGS_MODULE=test.settings ./manage.py test
This would work. Another way would be : ./manage.py --settings=test.settings test > Do you prefer that to having some kind of global variable indicating > tests are being run that the normal settings file could query to know > which db settings to use? It seems the TEST_DATABASE_NAME goes > partially in that direction -- why not go all the way? :-) There are many answers to this. Amongst them are: 1) Features: Using a test settings file means that you can customize _everything_ about your test environment, not just your database settings. 2) Documentation. Every extra setting is one more thing to document, one more thing to explain, and one more opportunity to confuse a user. The TEST_DATABASE_NAME option exists for the simple case to avoid name clashes when 'test_' + DATABASE_NAME isn't an available option. Documenting the 'test settings file' option keeps the documentation shorter, and therefore easier to explain. It is also a generic solution - it can be used for other problems, not just testing - so we can explain the general idea once, and then direct mulitple problems at the single solution. 3) Maintenance. The TEST_* settings you propose would need to mirror all the core database settings. This means that any modification to the core settings (say, adding a new option) will need to be mirrored in the test settings. This is something that could be easily overlooked, which means you're introducing a point of weakness for future developments. 4) Testing. Configuration complexity (as in the number of potential configurations) increases exponentially as you add settings; this increases the potential for clashing configurations, and therefore increases the number of configurations that need to be tested. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
