Django cuándo usar el método de desmontaje

Question

De acuerdo con los documentos:

Un TestCase, por el contrario, no trunca las tablas y volver a cargar 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 retrotrae al final de la prueba . También evita que el código bajo prueba emita cualquier confirmación o operaciones de retrotracción de en la base de datos, para garantizar que la reversión al al final de la prueba restaura la base de datos a su estado inicial. En para garantizar que todos los códigos TestCase comiencen con una base de datos limpia , el corredor de prueba Django ejecuta primero todas las pruebas TestCase antes de cualesquiera otras pruebas (por ejemplo, doctest) que puedan alterar la base de datos sin restaurándola a su estado original.

Así que si tengo una prueba que se parece a esto:

class GeneralUserCreateTest(TestCase): 

    def setUp(self): 
     create_roletypes() 
     create_permissiontypes() 
     self.client = Client() 
     self.event = create_event() 

    def test_create(self): 
     create_url = reverse('event_user_signup', args=[self.event.slug]) 

     post_data = { 
      'signup-account-email': 'foo@bar.com', 
      'signup-account-password': 'foobar', 
      'signup-account-password2': 'foobar', 
      'signup-account-first_name': 'Foo', 
      'signup-account-last_name': 'Bar', 
     } 
     response = self.client.post(create_url, data=post_data) 
     self.assertEqual(response.status_code, 302) 

     # check creation of user object 
     self.assertEqual(User.objects.filter(email=post_data['signup-account-email']).count(), 1) 
     user = User.objects.get(username=post_data['signup-account-email']) 

     # user and profile objects created 
     self.assertEqual(User.objects.all().count(), 1) 
     self.assertEqual(Profile.objects.all().count(), 1) 

     # get the first user and profile object to test against submitted field 
     user = User.objects.all()[0] 
     profile = Profile.objects.all()[0] 
     role = Role.objects.filter(event=self.event, profiles=profile)[0] 
     self.assertEqual(role.roletype.name, 'General') 
     self.assertEqual(user.username, post_data['signup-account-email']) 
     self.assertEqual(user.email, post_data['signup-account-email']) 
     self.assertEqual(profile.first_name, post_data['signup-account-first_name']) 
     self.assertEqual(profile.last_name, post_data['signup-account-last_name']) 

¿Sigue siendo necesario ejecutar un método teardown o tiene la clase TestCase cuidar de él? Si es así, ¿cuándo se debe usar el método teardown dada la disponibilidad de la clase TestCase?

Answer 1

Para los fines de la base de datos, tearDown es bastante inútil, porque cada prueba se ejecuta en una transacción. Sin embargo, no todo en una prueba involucra la base de datos. Puede probar la creación/lectura de archivos, los procesos de derivación, las conexiones de red abiertas, etc. Este tipo de cosas generalmente requieren que las "cierre" después de que haya terminado. Esto es para lo que tearDown es, es decir, limpiar cosas de su método setUp, no relacionadas con la base de datos. (Sin embargo, si estuviese conectándose directamente a una base de datos, es decir, como las pruebas reales de Django deben hacer para asegurarse de que todo el material DBAPI funciona correctamente, también debería hacer una limpieza).

Answer 2

Si usted utilizando una base de datos alternativa como MongoDB o Redis y necesita cargar un conjunto de datos iniciales (una "colección"), también deberá anular el método tearDown.

Ver http://www.belchak.com/2011/02/07/unit-testing-django-with-a-nosql-backend/

En general, django.test.TestCase hace un color base de datos completa en el inicio de cada nueva prueba . Esto significa que no necesitamos eliminar manualmente objetos en nuestro tearDown como Chris Pratt mencionó anteriormente. El próximo setup de prueba se asegurará de que la base de datos esté limpia.

Sin embargo, si estamos utilizando doctests y unittest.TestCase, no habrá un lavado de la base de datos antes de que se vuelvan a ejecutar las pruebas. Al comienzo de una prueba, la base de datos estará en el estado que haya dejado la prueba anterior . Esto significa que cualquier información perdida dejada por una ejecución previa causaría conflicto. Entonces, si estamos usando doctests o unittest.TestCase para nuestras pruebas de django, una limpieza puede ser una buena práctica.

Finalmente, en escenarios más complicados, también puede tener sentido insistir deliberadamente en la base de datos de prueba para buscar fallas de prueba de unidades específicas.

Answer 3

Estaba trabajando en un proyecto que manejaba algunas cargas de archivos, y necesitaba eliminar los archivos creados por la prueba y el método tearDown fue muy útil en esa situación.

import shutil 

#.... 
#.... 

    def tearDown(self): 
     shutil.rmtree(settings.UPLOAD_ROOT)