CODEWITHSUNDEEP
pythondjangounit-testing
Dylan Klomparens
Dylan Klomparens

Reputation: 2942

Django unit test database not being torn down?

I have some unit tests I've written to test my Django application. One test suite in particular has a lot of code in its setUp() function. The purpose of said code is to create test data for the database. (Yes I know about fixtures and have chosen not to use them in this case). When I run the unit test suite the first test that is run passes, but then the rest of the tests in the suite fail. The message for all the failures is the same: it mentions that the error's location is "self.database_object.save()" and that the cause is "IntegrityError: column name is not unique". So, my best guess is that Django is not tearing down the database properly after each test.

Earlier today it was working, but I guess some refactoring I did messed it up. Any ideas on why Django is not properly tearing down the database after each test?

Upvotes: 9

Views: 6511

Answers (2)

Carcigenicate
Carcigenicate

Reputation: 45826

Just in case anyone else wasn't helped by the existing answer, I ended up having similar behavior because I did something dumb with inheritance. I had tests in a parent class that relied on only a single thing having been created. I then subclassed it and added a second item in the setup:

class BaseTestCase(TestCase):
    def setUp(self):
        super().setUp()
        # Create model instance and save it

    def test_ensure_one_created(self):
        # Assert a single thing was saved from the setup

class ChildTestCase(BaseTestCase):
    def setUp(self):
        super().setUp()
        # Create another model instance and save it

The issue was, test_ensure_one_created was failing because two items existed at the time of the test. The test only failed if I tested the entire test script though. If I ran the method directly, it succeeded.

As far as I can tell, this is because when the ChildTestCase class runs its tests, it does its setup, then runs all the base test methods again with its own. The solution was to split up the base classes and refrain from tests on them directly, then inherit from them and put tests on the child classes:

class SingleTestCaseBase(TestCase):
    def setUp(self):
        super().setUp()
        # Create model instance and save it

class MultiTestCaseBase(SingleTestCaseBase):
    def setUp(self):
        super().setUp()
        # Create another model instance and save it

class ChildSingleTestCase(SingleTestCaseBase):
    # Tests

class ChildMultiTestCase(MultiTestCaseBase):
    # Tests

There are likely better ways of setting this up, but that's beyond the point when trying to identify the cause. Hopefully, this helps someone else figure out their weird behavior.

Upvotes: 1

Tisho
Tisho

Reputation: 8492

Do you use TestCase or TransactionTestCase for your base class? Sometimes this behavior is related to the optimization Django makes for TestCase in favor of TransactionTestCase. Here is the difference:

https://docs.djangoproject.com/en/dev/topics/testing/?from=olddocs#django.test.TransactionTestCase

class TransactionTestCase

Django TestCase classes make use of database transaction facilities, if available, to speed up the process of resetting the database to a known state at the beginning of each test. A consequence of this, however, is that the effects of transaction commit and rollback cannot be tested by a Django TestCase class. If your test requires testing of such transactional behavior, you should use a Django TransactionTestCase.

TransactionTestCase and TestCase are identical except for the manner in which the database is reset to a known state and the ability for test code to test the effects of commit and rollback. A TransactionTestCase resets the database before the test runs by truncating all tables and reloading initial data. A TransactionTestCase may call commit and rollback and observe the effects of these calls on the database.

A TestCase, on the other hand, does not truncate tables and reload initial data at the beginning of a test. Instead, it encloses the test code in a database transaction that is rolled back at the end of the test. It also prevents the code under test from issuing any commit or rollback operations on the database, to ensure that the rollback at the end of the test restores the database to its initial state. In order to guarantee that all TestCase code starts with a clean database, the Django test runner runs all TestCase tests first, before any other tests (e.g. doctests) that may alter the database without restoring it to its original state.

Upvotes: 11

Related Questions