On Thu, 2006-06-29 at 14:40 +0000, [EMAIL PROTECTED] wrote: > Adrian Holovaty wrote: > > On 6/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Is it appropriate to have a test that requires sqlite, or should tests > > > always use the database engine(s) specified in settings? > > > > Tests should always use the database engines in settings. > > Ok. > > > > 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? > > > > It should work the way it works currently: It should attempt to create > > a test database (or databases). If any database of that name already > > exists, it should display a confirmation message. (Does this answer > > your question?) > > Almost. I'll try to ask more clearly. The question is: say I have a > test that requires connections in settings.DATABASES named 'a' and 'b'. > If there are no such DATABASES keys, should the test just stop with an > error saying: "This test requires connections in settings.DATABASES > named 'a' and 'b'", or should it create test databases for the keys it > needs, using the default settings as the template? Or is there a better > way to handle this that I haven't thought of? (If the keys do exist, I > assume that creating test databases and attaching to those names is the > right thing to do, and that will be done in runtests.py.)
A comparison with the current tests might be useful here: although I believe you have to specify a DATABASE_NAME setting in the settings file you pass to the tests, it isn't used at the moment. Instead, the django_test database name is always used (except for SQLite's in-memory case). And we assume the user running the tests has "create database" permissions, since we create the database when the tests start and delete it at the end. So wouldn't the analogous situation in your case be to also reserve django_test_a and django_test_b names as databases we will create in the test framework and then use those? > > Also, for sqlite, as far as I know there's no way to create multiple > in-memory databases at the same time; is it ok to use temp files for > this, or should the tests just not run with sqlite? Use temp files. We cannot avoid testing one whole database arm (unless it's because the database in question is missing a feature, such as transactions with MySQL). > > > > 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.) > > > > Yeah, I'm a bit hesitant to do this -- only because the model tests > > double as our "model examples" documentation, and for that use it's > > essential that the examples be clear. > > I should have looked at the doc generator before asking that, sorry -- > I didn't understand how it worked. How about, instead, updating > runtests so that it resets settings between tests? The reason this is > needed is that the multiple db test needs to test and document how to > create DATABASES settings, and I don't want to leave side-effects > sitting around after the test. Now much variation is there going to be in your test frameworks? From your earlier descrption of how the configuration works, it sounded like the settings were pretty fixed: a mapping of strings to database params. So can't you just use the same settings throughout, or are there various setups that induce different behaviour? Our current tests do not play around with configuration at all, so I'm wondering if you need to do this or if we can just assume a fixed settings setup. The documentation of this should go in the docs, not the tests. Unless there is some subtlety that means users of the code need to have a deep awareness of the settings at the time they write the code (which would seem to be problematic). I'm sure you are not just throwing these out to see how they sound, so I'm probably missing something. Is changing the settings in the midst of a test run necessary? Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
