Malcolm,
Thank you. You questions have actually answered a few of mine. For
those that are left, I'll try to clarify...
> 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?
The runtests.py that I checked in today does something similar --
increments a counter for each test database it creates. But that
doesn't solve the problem, which I can see I'm not explaining very
well. An example might help. In the implementation I'm working on, a
DATABASES property is added to settings, which is a dict, like this:
DATABASES = {
'a': { 'DATABASE_ENGINE': 'postgres',
'DATABASE_NAME': 'whatever',
# ...
},
'b': { 'DATABASE_ENGINE': 'postgres',
'DATABASE_NAME': 'something',
# ...
},
'tmp': { 'DATABASE_ENGINE': 'sqlite3',
'DATABASE_NAME': ':memory:'
}
}
What I need for testing are predictable keys in that dict, since those
are the names of the connections. The name is what a model specifies to
indicate that it uses a non-default connection, like:
class Zoo(models.Model):
# ...
class Meta:
db_connection = 'a'
(Likewise for transactions: transaction.commit(['a','b'])... ) So if my
test models need connection 'a', I can either have the tests fail if
there's no 'a' in DATABASES, or (if settings are reset between tests) I
can set the settings I need inside of the tests themselves. The spirit
of earlier answers seems to be "don't touch settings," so I'll go with
the error option unless it just won't work at all, or someone has a
better idea.
> 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.
There shouldn't be any need to change settings, beyond what I've
described above. If the right thing to do is to just punt on the tests
if they can't find the settings they need, then there's no need to
change any settings at all.
> The documentation of this should go in the docs, not the tests.
This is where I really misunderstood things, and I think that's why
some of my earlier questions were sort of obtuse. I thought that all of
the docs on the site were built from the doctests. I hadn't looked at
the *.txt files in docs to see that they aren't meant to be executable.
So that really answers the biggest question, which was "how can I write
tests for these settings values and have them get into the docs" -- the
answer is, I don't, the docs and tests are separate. On the one hand
that makes things a lot simpler, but on the other hand it makes me
concerned about docs being wrong or out of sync with the tests -- how
do you generally handle that?
> 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?
Mainly I'm trying to figure out how you all want the tests structured,
since the django test suite is not very much like a test suite I would
put together. :)
My main personal project is a test runner
(http://somethingaboutorange.com/mrl/projects/nose/) and I have some
strong prejudices about how to do unit testing that don't match up well
with how the django tests are put together -- so I'm going a little
overboard with the questions, because I don't want to impose my own
testing methods where they aren't wanted, without knowing I'm doing it,
because I'm making assumptions about how things "ought to work." Now I
think I have a pretty good idea, finally, of what's expected, so I'll
get back to hacking and wait for somebody to tell me where I've got it
wrong. :)
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
-~----------~----~----~----~------~----~------~--~---
