Django TransactionTestCase with rollback emulation

Question

I am using Django 1.7.7 with python 2.7.6 and Postgres as a database, and I am having a problem with TransactionTestCase . In my migrations, I had two data types, and I wanted them to be available during the tests, so I added serialized_rollback = True to my test case ( https://docs.djangoproject.com/en/1.7/topics/testing / overview / # test-case-serialized-rollback ).

The first test case test was fine, but then django complained about IntegrityError :

 IntegrityError: duplicate key value violates unique constraint "django_content_type_app_label_6032a1f08b99c274_uniq" DETAIL: Key (app_label, model)=(admin, logentry) already exists. 

I managed to run the tests and avoid this error by adding the following parameters to my settings ( https://docs.djangoproject.com/en/1.7/ref/settings/#std:setting-TEST_NON_SERIALIZED_APPS ):

 TEST_NON_SERIALIZED_APPS = ['django.contrib.contenttypes', 'django.contrib.auth'] 

But I would like to know why this is necessary? Is it a rollback error or is it a problem on my side?

Answer 1

This issue is really well explained in the django-related ticket: https://code.djangoproject.com/ticket/23727

Quote from there:

When using TransactionTestCase with serialized_rollback = True after creating the database and migrating it (along with emitting a post_migrate signal), the contents of the database are serialized into _test_serialized_contents.

After the first test case, _fixture_teardown () will clear the tables, but then the post_migrate signal will come out, and new rows will be created in the django_content_type table (with new PKs).

Then, in any subsequent test cases, the _fixture_setup () set tries to deserialize the contents of _test_serialized_contents, but these lines are identical to the lines already in the database, except for their PC.

This raises an IntegrityError due to a unique constraint in the django_content_type table.

The patch was created / released, but only for Django 1.9.x.

For previous versions, you should continue to use TEST_NON_SERIALIZED_APPS, I think ...