¿Cómo cargar los accesorios solo una vez en las pruebas de django unit?

Question

En pruebas de unidad I necesidad de cargar accesorios, como a continuación:

class TestQuestionBankViews(TestCase): 

     # Load fixtures 
     fixtures = ['qbank'] 

     def setUp(self):       
      login = self.client.login(email="mail@gmail.com",password="welcome")   


     def test_starting_an_exam_view(self):    
      candidate = Candidate.objects.get(email="mail@gmail.com") 
      .......etc 


     def test_review_view(self): 
      self.assertTrue(True)    
      ......... 

     def test_review_view2(self): 
      self.assertTrue(True) 
      ......... 

Problema:

Estos accesorios están cargando para cada prueba, es decir, antes test_review_view, test_review_view2, etc ., ya que Django vacía la base de datos después de cada prueba.

Este comportamiento está provocando que las pruebas tarden mucho tiempo en completarse.

¿Cómo puedo evitar la carga de este dispositivo redundante?

¿Hay alguna manera de cargar dispositivos en setUp y lavarlos cuando termine la clase de prueba, en lugar de enjuagarlos entre cada prueba?

Answer 1

Me encontré con el mismo problema. En general, no hay una manera realmente buena de hacer eso usando el corredor de prueba de django. Usted podría estar interesado en esto thread

Dicho esto, si todas las cajas de prueba utilizan el mismo dispositivo, y no modifican los datos de ninguna manera, entonces el uso de initial_data funcionaría.

Answer 2

Tuve un problema similar una vez y terminé escribiendo mi propio corredor de prueba. En mi caso initial_data no era el lugar correcto ya que initial_data se cargaría durante syncdb, algo que no quería. Anulé los métodos setup_ y teardown_test_environment para cargar mi dispositivo personalizado antes de que se ejecutara el conjunto de pruebas y para eliminarlo una vez hecho.

Answer 3

Usando django-nose y un poco de código, puede hacer exactamente lo que usted solicitó. Con django-nose, puede tener funciones de configuración y desmontaje por paquete, por módulo y por clase. Eso le permite cargar sus dispositivos en una de las funciones de configuración superiores e inhabilitar el reinicio de django.test.TestCase de los dispositivos entre las pruebas.

Aquí es un archivo de prueba de ejemplo:

from django.test import TestCase 
from django.core import management 

    def setup(): 
     management.call_command('loaddata', 'MyFixture.json', verbosity=0) 

    def teardown(): 
     management.call_command('flush', verbosity=0, interactive=False) 

    class MyTestCase(TestCase): 

     def _fixture_setup(self): 
      pass 

     def test_something(self): 
      self.assertEqual(1, 1) 

en cuenta que la instalación y el desmontaje están fuera de la clase. La configuración se ejecutará antes de todas las clases de prueba en este archivo, y el desmontaje se ejecutará después de todas las clases de prueba.

Dentro de la clase, verá el método def _fixture_setup (auto). Esto anula la función que restablece la base de datos entre cada prueba.

Tenga en cuenta que si sus pruebas escriben algo en la base de datos, esto podría invalidar sus pruebas. Por lo tanto, cualquier otra prueba que necesite dispositivos recargados para cada prueba debe colocarse en un archivo de prueba diferente.

Answer 4

O uso setUpModule:

def setUpModule(): 
    print 'Module setup...' 

def tearDownModule(): 
    print 'Module teardown...' 

class Test(unittest.TestCase): 
    def setUp(self): 
     print 'Class setup...' 

    def tearDown(self): 
     print 'Class teardown...' 

    def test_one(self): 
     print 'One' 

    def test_two(self): 
     print 'Two' 

impresiones:

Creating test database for alias 'default'... 
Module setup... 
Class setup... 
One 
Class teardown... 
Class setup... 
Two 
Class teardown... 
Module teardown... 

Answer 5

django-nariz ofrece una solución a este problema readymade: simplemente subclase django_nose.FastFixtureTestCase.

Además, django-nose admite el agrupamiento de accesorios, lo que puede acelerar aún más tus pruebas cargando solo cada conjunto único de accesorios una vez por prueba. Después de haber subclasificado FastFixtureTestCase donde corresponda, ejecute el corredor de prueba django-nose utilizando la opción --with-fixture-bundling.

Consulte django-nose on pypi para obtener más información.

Answer 6

Si no desea instalar un nuevo paquete solo para este fin, puede combinar Tom Wainwright's solution y mhost's solution.

En su testfile, añadir estas funciones fuera de las clases:

from django.core.management import call_command 

def setUpModule(): 
    call_command(
     'loaddata', 
     'path_to_fixture.json', 
     verbosity=0 
    ) 

def tearDownModule(): 
    call_command('flush', interactive=False, verbosity=0) 

Si no quieren tener estos accesorios cargados en la base de datos de todos los casos de prueba, split the test into multiple files mediante la creación de un nuevo directorio en el aplicación llamada tests, añadir un archivo vacío __init__.py para contar Python que se trata de un paquete, y añadir los archivos de prueba con nombres de archivo que comienzan con test, ya que el corredor buscará archivos que coincidan con el patrón test*.py

Answer 7

por lo que vale la pena , y dado que no hay una respuesta aceptada, Django 1.8 ahora ofrece esta funcionalidad lista para usar, siempre que esté utilizando un back-end de base de datos que admita transacciones.

También agrega el método TestCase.setUpTestData() para la creación manual de datos de prueba una vez por clase de TestCase.

Ver the Django 1.8 release notes.