Django manage.py test cannot load device correctly

Question

I wrote Django tests using django.test.TestCase, and I would like to use the instrument with all my current database data to run the tests. However, if I create the device as follows:

python manage.py dumpdata --indent=3 > myapp/fixtures/test_data.json 

when I run tests using python manage.py test myapp , I get the following error:

 Problem installing fixture...(traceback) IntegrityError: Could not load auth.Permission(pk=42): duplicate key value violates unique constraint "auth_permission_content_type_id_codename_key" DETAIL: Key (content_type_id, codename)=(14, add_record) already exists. 

I read SO somewhere that this could be caused by a pk conflict, so I tried to recreate the device with:

 python manage.py dumpdata --natural --indent=3 > myapp/fixtures/test_data.json 

But now running the test gives me:

 Problem installing fixture...(traceback) DeserializationError: 'NoneType' object has no attribute '_meta' 

I also tried differently to exclude (using the --exclude parameter) auth.permission and contenttypes (or both at the same time), but then I get complaints about missing permissions ( Key (permission_id)=(44) is not present in table "auth_permission". ) or missing content types ( DeserializationError: ContentType matching query does not exist. )

In any case, I need permissions, because my tests partially confirm that only users with certain permissions can access certain views.

I don’t understand why this is happening, to be honest, my impression was that the test runner starts with a completely clean database and loads EVERYTHING from my device, but reading messages like this: Django unit testing with loading for several dependent application tasks seems to be , it is not so.

How can I get around this? I would prefer not to write things like User.objects.create_user(.. tons of times under def setUp(self): in my tests, to have enough objects so that they can work fine ...

Answer 1

When you run the test, the initial_data fixtures will be loaded (via syncdb ) .

For me, dumpdata works with the --natural argument, with the exception of contenttypes , and then a few auth.permission entries are auth.permission , which only remain:

 { "pk": 1, "model": "auth.permission", "fields": { "codename": "add_permission", "name": "Can add permission", "content_type": [ "auth", "permission" ] } }, { "pk": 2, "model": "auth.permission", "fields": { "codename": "change_permission", "name": "Can change permission", "content_type": [ "auth", "permission" ] } }, { "pk": 3, "model": "auth.permission", "fields": { "codename": "delete_permission", "name": "Can delete permission", "content_type": [ "auth", "permission" ] } }, { "pk": 4, "model": "auth.permission", "fields": { "codename": "add_group", "name": "Can add group", "content_type": [ "auth", "group" ] } }, { "pk": 5, "model": "auth.permission", "fields": { "codename": "change_group", "name": "Can change group", "content_type": [ "auth", "group" ] } }, { "pk": 6, "model": "auth.permission", "fields": { "codename": "delete_group", "name": "Can delete group", "content_type": [ "auth", "group" ] } }, { "pk": 7, "model": "auth.permission", "fields": { "codename": "add_user", "name": "Can add user", "content_type": [ "auth", "user" ] } }, { "pk": 8, "model": "auth.permission", "fields": { "codename": "change_user", "name": "Can change user", "content_type": [ "auth", "user" ] } }, { "pk": 9, "model": "auth.permission", "fields": { "codename": "delete_user", "name": "Can delete user", "content_type": [ "auth", "user" ] } }, { "pk": 10, "model": "auth.permission", "fields": { "codename": "add_contenttype", "name": "Can add content type", "content_type": [ "contenttypes", "contenttype" ] } }, { "pk": 11, "model": "auth.permission", "fields": { "codename": "change_contenttype", "name": "Can change content type", "content_type": [ "contenttypes", "contenttype" ] } }, { "pk": 12, "model": "auth.permission", "fields": { "codename": "delete_contenttype", "name": "Can delete content type", "content_type": [ "contenttypes", "contenttype" ] } }, { "pk": 13, "model": "auth.permission", "fields": { "codename": "add_session", "name": "Can add session", "content_type": [ "sessions", "session" ] } }, { "pk": 14, "model": "auth.permission", "fields": { "codename": "change_session", "name": "Can change session", "content_type": [ "sessions", "session" ] } }, { "pk": 15, "model": "auth.permission", "fields": { "codename": "delete_session", "name": "Can delete session", "content_type": [ "sessions", "session" ] } }, { "pk": 16, "model": "auth.permission", "fields": { "codename": "add_site", "name": "Can add site", "content_type": [ "sites", "site" ] } }, { "pk": 17, "model": "auth.permission", "fields": { "codename": "change_site", "name": "Can change site", "content_type": [ "sites", "site" ] } }, { "pk": 18, "model": "auth.permission", "fields": { "codename": "delete_site", "name": "Can delete site", "content_type": [ "sites", "site" ] } }, 

I don’t understand why, but it works. I would try to compare my device with the dump of a new database right after syncdb and decide what to delete or edit on my device. Hope this helps in your case.

Answer 2

The problem is still present, even with --natural. However, this seems to be allowed in django1.9 with new flags: dumpdata --natural-foreign --natural-primary

see https://code.djangoproject.com/ticket/21278#commenthaps