Before I check in too much more stuff to the new branch, I wanted to poll everyone on how to properly handle the sorts of tests that multiple db support is going to need.
I've checked in the basic config-level changes (supporting settings.DATABASES and django.db.connections), and test file for them that I think should be in modeltests but currently has to be in othertests because modeltests offers no setup/teardown, and without those, it would be leaving little sqlite3 dbs all over /tmp forever and side-effecting settings in an unfortunate way. Here's the test file: http://code.djangoproject.com/browser/django/branches/multiple-db-support/tests/othertests/multiple_databases.py That in mind, here are my first batch of testing questions: Is it appropriate to have a test that requires sqlite, or should tests always use the database engine(s) specified in settings? If they should always use the engines in settings, when needing multiple databases, is it appropriate to kill the test with an error specifying how the settings must be set up for the test to run when the needed databases are not defined? Or should the test create the databases it needs using the default engine? Are there any objections to my adding setup/teardown support for model tests? (Basically: run module.setup() if defined before running tests; run module.teardown() if defined after running tests.) Are there any objections to my extending the test db setup/teardown in runtests to include creating and destroying test dbs for all dbs defined in DATABASES? Thanks, JP --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
