¿La base de datos de prueba de la unidad Django no está siendo destruida?

Question

Tengo algunas pruebas de unidad que he escrito para probar mi aplicación Django. Un conjunto de pruebas en particular tiene un montón de código en su función setUp(). El propósito de dicho código es crear datos de prueba para la base de datos. (Sí, sé de los accesorios y he decidido no usarlos en este caso). Cuando ejecuto el conjunto de pruebas unitarias pasa la primera prueba que se ejecuta, pero luego el resto de las pruebas en el conjunto falla. El mensaje para todos los errores es el mismo: menciona que la ubicación del error es "self.database_object.save()" y que la causa es "IntegrityError: el nombre de la columna no es único". Entonces, mi mejor suposición es que Django no está destruyendo la base de datos correctamente después de cada prueba.

Hoy estaba funcionando, pero supongo que alguna refactorización lo eché a perder. ¿Alguna idea sobre por qué Django no destruye la base de datos después de cada prueba?

Answer 1

¿Utiliza TestCase o TransactionTestCase para su clase base? A veces, este comportamiento está relacionado con la optimización que hace Django para TestCase a favor de TransactionTestCase. Aquí está la diferencia:

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.