Just ran the new code with our tests and about 2/3 of them became
broken. My first hypothesis is it's caused by testing views with
self.client. We use TransactionMiddleware that explicitly commits
transaction on view's successful return. So the first test that does
"self.client.get(...)" leaves fixtures data in the database and all
subsequent attempts to load the same fixtures are failing.
Now I'm thinking about somehow disabling TransactionMiddleware from
within test environment. But is seems hacky...
Sorry, wrote too soon. Disabling TransactionMiddleware didn't help. I'll
investigate further.
Just ran the new code with our tests and about 2/3 of them became
Karen Tracey wrote:
> For the most part this change should be invisible, except for the speed
> improvement when running tests. However, if you have tests that need to
> actually test the effects of transaction commit or rollback, you will
> now need to use a django.test.TransactionTestCase instead of a
> django.test.TestCase.
broken. My first hypothesis is it's caused by testing views with
self.client. We use TransactionMiddleware that explicitly commits
transaction on view's successful return. So the first test that does
"self.client.get(...)" leaves fixtures data in the database and all
subsequent attempts to load the same fixtures are failing.
I've found it. My fault, as usually :-). But an interesting corner case
too.
We're using mysql_replicated db backend that basically has two
connections. The first ("master") is active by default and is used when
loading fixtures. Then a test calls a db-read-only view and all its
interactions with the db go intto another ("slave") connection which
doesn't see any data changed in the master because it didn't commit.
Thus a test fails because the db is absolutely empty.
Now I'm going to implement a switch for the backend ensuring that only
one connection is used and it'll be used in test environment.
I'm seeing some failures exclusively under PgSQL: http://dpaste.com/109831/ . I'm not sure what's causing them, but it's just the admin views tests, no other ones.
I've found it. My fault, as usually :-). But an interesting corner case
too.
We're using mysql_replicated db backend that basically has two
connections. The first ("master") is active by default and is used when
loading fixtures. Then a test calls a db-read-only view and all its
interactions with the db go intto another ("slave") connection which
doesn't see any data changed in the master because it didn't commit.
Thus a test fails because the db is absolutely empty.
Now I'm going to implement a switch for the backend ensuring that only
one connection is used and it'll be used in test environment.
PgSQL is indeed PostgreSQL. Yes, I do still get the failures pre-fast tests, I guess I'd never run those tests. I would like to say that when I went back to test that the tests were unbearably slow, so that makes me super happy about the new fast tests, thanks for all your hard work.