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

Tengo algunas pruebas unitarias que he escrito para probar mi aplicación Django. Un conjunto de pruebas en particular tiene mucho 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í, conozco los accesorios y he optado por no usarlos en este caso). Cuando ejecuto el conjunto de pruebas de unidad, la primera prueba que se ejecuta pasa, pero luego el rest de las pruebas en el conjunto fallan. El mensaje para todas las fallas 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 conjetura es que Django no está destruyendo la base de datos correctamente después de cada prueba.

Anteriormente, hoy estaba funcionando, pero creo que algo de refactorización lo estropeé. ¿Alguna idea sobre por qué Django no está destruyendo correctamente la base de datos después de cada prueba?

¿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

clase TransactionTestCase

Las clases de Django TestCase hacen uso de las instalaciones de transacciones de la base de datos, si están disponibles, para acelerar el proceso de restablecer la base de datos a un estado conocido al comienzo de cada prueba. Una consecuencia de esto, sin embargo, es que los efectos de la confirmación de transacción y la reversión no pueden ser probados por una clase Django TestCase. Si su prueba requiere la prueba de tal comportamiento transaccional, debe usar un Django TransactionTestCase.

TransactionTestCase y TestCase son idénticos, excepto por la manera en que la base de datos se restablece a un estado conocido y la capacidad del código de prueba para probar los efectos de la confirmación y la reversión. Un TransactionTestCase restablece la base de datos antes de que la prueba se ejecute truncando todas las tablas y recargando los datos iniciales. Un TransactionTestCase puede llamar a commit y rollback y observar los efectos de estas llamadas en la base de datos.

Un TestCase, por otro lado, no trunca las tablas y recarga los datos iniciales al comienzo de una prueba. En su lugar, incluye el código de prueba en una transacción de base de datos que se revierte al final de la prueba . También evita que el código en prueba emita operaciones de confirmación o retrotracción en la base de datos, para garantizar que la reversión al final de la prueba restaure la base de datos a su estado inicial. Para garantizar que todo el código de TestCase comience con una base de datos limpia, el corredor de prueba de Django ejecuta todas las pruebas de TestCase primero, antes de cualquier otra prueba (por ejemplo, doctests) que pueda alterar la base de datos sin restaurarla a su estado original.