Wednesday, May 4, 2016

Fixtures won't load twice in same testcase


I'm having a strange problem.  My test environment has been working fine, but I am upgrading my environment's Django revision slowly, which means I also need to move away from django-nose's FastFixtureTestCase.

I'm now at Django 1.7.   I have a TestCase which is more or less...

class Foo(TestCase): # and I've tried TransactionTestCase

    fixtures = ['accounts.json', 'config.json', 'runtimedata.json']

    def test1(self):
        pass # yes, literally.

    def test2(self):
        pass # literally, pass right now


If I split test1 and test2 into two classes, the TestCase works fine.

Otherwise, my runtimedata app fixture ends up with a duplicate row for the second test during the fixture setup phase.   When I turned on postgres (9.2) logging, I get:

LOG:  statement: UPDATE "runtimedata_branch" SET "name" = 'mock' WHERE "runtimedata_branch"."id" = 1
LOG:  statement: INSERT INTO "runtimedata_branch" ("id", "name") VALUES (1, 'mock')
ERROR:  duplicate key value violates unique constraint "runtimedata_branch_name_49810fc21046d2e2_uniq"
DETAIL:  Key (name)=(mock) already exists.
STATEMENT:  INSERT INTO "runtimedata_branch" ("id", "name") VALUES (1, 'mock')
LOG:  statement: ROLLBACK
LOG:  statement: DROP DATABASE "test_db"

If I grep for runtimedata_branch in the postgres logs, I get ...starting after the TRUNCATE caused by TransactionTestCase ....

LOG:  statement: TRUNCATE [...], "runtimedata_branch", [...]; #
LOG:  statement: SELECT "runtimedata_branch"."id", "runtimedata_branch"."name" FROM "runtimedata_branch" WHERE "runtimedata_branch"."name" = 'mock' LIMIT 21
LOG:  statement: INSERT INTO "runtimedata_branch" ("name") VALUES ('mock') RETURNING "runtimedata_branch"."id"
LOG:  statement: UPDATE "runtimedata_branch" SET "name" = 'mock' WHERE "runtimedata_branch"."id" = 1
LOG:  statement: INSERT INTO "runtimedata_branch" ("id", "name") VALUES (1, 'mock')
ERROR:  duplicate key value violates unique constraint "runtimedata_branch_name_49810fc21046d2e2_uniq"
STATEMENT:  INSERT INTO "runtimedata_branch" ("id", "name") VALUES (1, 'mock')

You can see a different pattern for the first pass fixture loading for test1,

LOG:  statement: INSERT INTO "runtimedata_branch" ("name") VALUES ('mock') RETURNING "runtimedata_branch"."id"
LOG:  statement: UPDATE "runtimedata_branch" SET "name" = 'mock' WHERE "runtimedata_branch"."id" = 1

The main difference I can see is the first time, the tables are generated from scratch, the second the tables have been truncated.  Note, I get a very similar outcome with TestCase which does rollbacks instead of truncates.

Any ideas?  This is very odd.

Also, my fixtures are dumped with --natural.  I've just tried it without --natural and I get the same outcome.



--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/89730e77-2099-4219-9e75-34ccc3b4f457%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment