2010-05-05 16 views
6

Django (1.2 beta) restablecerá las bases de datos entre cada prueba que se ejecuta, lo que significa que cada prueba se ejecuta en un DB vacío. Sin embargo, la (s) base (s) de datos no están enjuagadas. Uno de los efectos de vaciar la base de datos es que los contadores auto_increment se restablecen.¿Puede Django purgar su (s) base (s) de datos entre cada prueba unitaria?

Considerar una prueba que toma los datos de la base de datos de clave principal:

class ChangeLogTest(django.test.TestCase): 
    def test_one(self): 
     do_something_which_creates_two_log_entries() 
     log = LogEntry.objects.get(id=1) 
     assert_log_entry_correct(log) 
     log = LogEntry.objects.get(id=2) 
     assert_log_entry_correct(log) 

Esto pasará ya que sólo dos entradas de registro se haya creado. Sin embargo, si se agrega otra prueba a ChangeLogTest y se ejecuta antes detest_one, las claves principales de las entradas de registro ya no son 1 y 2, podrían ser 2 y 3. Ahora test_one falla.

Esto es realmente una pregunta en dos partes:

  1. ¿Es posible forzar ./manage.py test para eliminar la base de datos entre cada caso de prueba?
  2. Dado que Django no vacía el DB entre cada prueba de manera predeterminada, tal vez haya una buena razón. ¿Alguien sabe?

Respuesta

7

es posible forzar ./manage.py prueba para eliminar la base de datos entre cada caso de prueba?

Eche un vistazo a la implementación del comando django.core.management.commands.flush.py.

puede llamar al comando ras del interior de su llamada de prueba (tal vez en TestCase.setUp):

management.call_command('flush') 

tal vez hay una buena razón. ¿Alguien sabe?

Sí, hay: Acelerar. Flushing y volver a cargar muchos datos de JSON toma un tiempo ...

Tal vez debería echar un vistazo a TransactionTestCase

8

La respuesta a esto es, no escribir sus pruebas de tal manera ya que dependen en particular valores clave Por ejemplo, la prueba podría ser mejor escrito:

def test_one(self): 
    do_something_which_creates_two_log_entries() 
    logs = LogEntry.objects.all() 
    assert_log_entry_correct(log[0]) 
    assert_log_entry_correct(log[1]) 
+0

supongo que eso funcionaría, ya que 'LogEntry.objects.all()' siempre devuelve los registros en el mismo orden (el aumento de la clave principal), ¿verdad? –

+0

no está definido, pero muy probablemente sí. Si quiere estar seguro, solo ordene los resultados por id –

+1

@Mike, Ivan: ..o agregue 'ordering = ('id',)' a Model.Meta –