On 5/16/2011 11:18 PM, Erik Rose wrote:
How about caching the test databases? The database state could be cached after
model setup (which takes some time if you've got lots of them) + initial data
fixture setup, and after the setup for each test case (fixtures + setUp()
method).
So, in the best case, no database setup is required at all to run tests --
which encourages test driven development :-)
So that would be 11 separate DBs for our tests, and you'd just switch between
them? Interesting idea. Or are you proposing caching the results of queries for
each test class, essentially mocking out the DB?
I'd been thinking recently about this as well: when you consider all the
test runs, they're very repetitive. Every time the tests are run, they
go through the same set of steps: a) create database, b) install
fixtures, c) run tests. Steps a, b, and c take too long. Step c is
what we're really interested in, and almost always, steps a and b have
the same outcome as the last time we ran them. We all know what to do
if an operation takes too long and usually is the same as last time:
cache its outcome. The outcome in this case is the state of the
database. Caching it could be as simple as making a copy of the
database after the fixtures are installed, then using that copy to run
tests.
The complications are: 1) in any interesting test suite, there isn't a
single outcome of a+b, because different tests will have different
fixtures and perhaps even different models, so a number of copies will
have to be captured. 2) As with any caching scheme, invalidation is
important and tricky. In the normal course of development, how will
these cached copies of the database be invalidated and recreated?
Perhaps this isn't so bad, it's roughly analogous to writing migrations,
which we know how to deal with.
I don't have any code to do this, but I envision a set of test
databases, with a modified test runner than knows how to cycle among
them by manipulating settings.DATABASES to use the proper one for each
test class. I'd be glad to help build such a thing, and may be working
toward it myself.
--Ned.
Perhaps some numbers would illuminate: I clock the total setup and teardown
time for support.mozilla.com's 1064 tests at 2.59 seconds after my
optimizations. So I'm pretty happy with that. :-) CPU use for the test run is
76% according to the `time` commands, so there's a little more I/O to kill but
not much.
Cheers,
Erik
--
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?hl=en.
