Django Tests: setUpTestData on Postgres throws: "Duplicate key value violates unique constraint"

I've been running into this issue sporadically for months now. I believe I just figured out the root cause and a couple solutions.

Summary For whatever reason, it seems like the Django test case base classes aren't removing the database records created by let's just call it TestCase1 before running TestCase2. Which, in TestCase2 when it tries to create records in the database using the same IDs as TestCase1 the database raises a DuplicateKey exception because those IDs already exists in the database. And even saying the magic word "please" won't help with database duplicate key errors.

Good news is, there are multiple ways to solve this problem! Here are a couple...

Solution 1

Make sure if you are overriding the class method tearDownClass that you call super().tearDownClass(). If you override tearDownClass() without calling its super, it will in turn never call TransactionTestCase._post_teardown() nor TransactionTestCase._fixture_teardown(). Quoting from the doc string in TransactionTestCase._post_teardown()`:

    def _post_teardown(self):
        """
        Perform post-test things:
        * Flush the contents of the database to leave a clean slate. If the
          class has an 'available_apps' attribute, don't fire post_migrate.
        * Force-close the connection so the next test gets a clean cursor.
        """

If TestCase.tearDownClass() is not called via super() then the database is not reset in between test cases and you will get the dreaded duplicate key exception.

Solution 2

Override TransactionTestCase and set the class variable serialized_rollback = True, like this:

class MyTestCase(TransactionTestCase):
    fixtures = ['test-data.json']
    serialized_rollback = True

    def test_name_goes_here(self):
        pass

Quoting from the source:

class TransactionTestCase(SimpleTestCase):

    ...

    # If transactions aren't available, Django will serialize the database
    # contents into a fixture during setup and flush and reload them
    # during teardown (as flush does not restore data from migrations).
    # This can be slow; this flag allows enabling on a per-case basis.
    serialized_rollback = False

When serialized_rollback is set to True, Django test runner rolls back any transactions inserted into the database beween test cases. And batta bing, batta bang... no more duplicate key errors!

Conclusion

There are probably many more ways to implement a solution for the OP's issue, but these two should work nicely. Would definitely love to have more solutions added by others for clarity sake and a deeper understanding of the underlying Django test case base classes. Phew, say that last line real fast three times and you could win a pony!

I continued to get this error without having any duplicate data but I was able to resolve the issue by initializing the object and calling the save() method rather than creating the object via Model.objects.create()

In other words, I did this:

@classmethod
def setUpTestData(cls):
    cls.person = Person(first_name="Jane", last_name="Doe")
    cls.person.save()

Instead of this:

@classmethod
def setUpTestData(cls):
    cls.person = Person.objects.create(first_name="Jane", last_name="Doe")