Hacer pruebas unitarias en la base de datos 'en vivo' en settings.py mientras usa 'manage.py test' de django.

Question

Si tiene una configuración de base de datos en Django, ¿cómo puede hacer que TestRunner use la base de datos 'Live' (según la configuración de la base de datos_* en settings.py) en lugar de ejecutarlos en la base de datos de prueba efímera.

Por ejemplo, me gustaría ejecutar la siguiente prueba en el live base de datos que se especifica en settings.py:

import unittest

from example import models

class DBDriverTest(unittest.TestCase): 
    db testDriver(self):
       "Connect to the live database and drop in sample value."
       m = models.MyModel('hello')
       m.save() # ... save to the live database from settings.py

En la actualidad, el código anterior guardará solo en la base de datos de prueba que se ha construido. Esto es muy limitante porque mi aplicación tiene múltiples procesos paralelos que funcionan en la base de datos, y mis pruebas unitarias estarán incompletas (e incoherentes) sin la capacidad de bombear las cosas a una base de datos 'en vivo' y ver dónde se mantienen después de un sueño corto.

Las dos opciones potenciales en las que puedo pensar son:

1. Conecte a través de la API Django para descubrir cómo "manualmente" conectarse a la base de datos en settings.py

2. Hacer una conexión de bajo nivel a la base de datos 'en vivo' y llenarla manualmente

El anterior es problemático porque dependería de las cosas debajo de la API pública de Django. Este último es problemático porque renuncia a la API de la base de datos django de base de datos y es más intensivo manualmente.

Estoy agradecido por sus pensamientos y aportes.

Brio

Answer 1

Tendrías que definir el tuyo test_runner tearDown Métodos, porque cada prueba se ejecuta de forma aislada y la base de datos se borra después de cada ejecución. Puedes hacer, lo que estás pidiendo simplemente construyendo el tuyo test_runner, lo hemos hecho una vez (aunque no fui yo en el equipo) con la base de datos a la que accedió los servicios web y durante algún tiempo no tuvimos forma de eliminar nada de allí, sino de eliminar manualmente toda la base de datos;-------- ) Esto fue bastante divertido.

Respondiendo a su pregunta: cree la suya propia test_runner y prepárate para crear el tuyo tearDown Métodos, en los que solo eliminará los objetos que creó. De alguna manera debes almacenar allí primary keys, por lo que no eliminará nada de la base de datos en vivo.

Sin embargo, No creo que esta sea una buena manera de hacerlo. Ejecución de pruebas en la base de datos en vivo se pregunta por un desastre. Tarde o temprano te meterás en problemas con esto. Lo que debe hacer en su lugar es volcar su base de datos en vivo, prepararse accesorios A partir de estos datos y úselos en sus pruebas. Esto está bien documentado y fácilmente hecho. De esta manera, tendrá un entorno en vivo sin arriesgar sus valiosos datos y no necesita escribir el suyo propio test_runner. Esta es la mejor y más segura forma de seguir en mi opinión.