Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

219
Vistas
¿Cómo probar migraciones más rápido en Django?

He intentado escribir una prueba en archivos de migración específicos . Básicamente, quería probar el estado actual de la base de datos y los datos entre un par de migraciones. Usé MigrationExecutor de la siguiente manera:

 executor = MigrationExecutor(connection) old_apps = executor.loader.project_state(self.migrate_from).apps executor.migrate(self.migrate_from) # do something here executor.migrate(self.migrate_to)

Tenemos tantos archivos de migración en el proyecto, por lo que ejecutarlos todos con pruebas unitarias lleva mucho tiempo. Por lo general, configuraría los módulos de migración en None en settings_test.py :

 MIGRATION_MODULES: { 'my_app': None }

Con esta configuración, la prueba se ejecutaría muy rápido. El problema es que los archivos de migración para probar ( self.migrate_from y self.migrate_to ) ya no se pueden encontrar:

 django.db.migrations.exceptions.NodeNotFoundError: Node ('poleluxe', '0090_auto_previous_migration') not a valid node

Así que tuve que incluir los módulos de migración nuevamente en la prueba.

¿Hay alguna forma de incluir archivos de migración sin ejecutarlos todos? En mi caso, quiero omitir todas las migraciones de 0001 a 0089 y ejecutar solo 0090 (como self.migration_from ) y 0091 (como self.migrate_to ).

Estoy pensando en aplastar las primeras 89 migraciones y poner el resultado en una carpeta separada junto con 0090 y 0091 , luego referirme a esa carpeta de migración en la prueba. Sin embargo, no estoy seguro de si esto sería una gran solución.

about 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

Esto es lo que entiendo hasta ahora, por favor guíame si no estoy en lo correcto.

El problema

  1. El código de prueba de migración necesita que se aplique la migración.
  2. Django comienza antes que cualquier otro proceso como @override_setting y setUpClass()

La solución

Anule la configuración de MIGRATION_MODULES al comienzo de TestClass, incluso cuando TestClass no se inicializó por completo porque ahí es donde solo encontré el punto correcto.

De esta manera, no solo puede deshabilitar toda la migración para acelerar cuando ejecuta sus pruebas, sino que también puede probar los archivos de migración.

  1. Deshabilite toda la migración desde settings.py .

     MIGRATION_MODULES = {app: None for app in INSTALLED_APPS}
  2. (Opcional) Elimine las opciones --nomigrations de la configuración de pytest si usa pytest-django.
  3. Anule la configuración de 'MIGRATION_MODULES' y vuelva a configurarla después de la prueba.

     class TestMigrations(TestCase): origin_modules = getattr(settings, 'MIGRATION_MODULES', {}) setattr(settings, 'MIGRATION_MODULES', {}) ... @classmethod def tearDownClass(cls): setattr(settings, 'MIGRATION_MODULES', cls.origin_modules) super().tearDownClass()

Información de prueba

  1. @override_setting en TestClass o TestMethod No funciona porque Django inicia y ejecuta la migración antes que la decoración de @override_setting
  2. pytest-django con --nomigrations No funciona , no estoy tan seguro, pero mi solución es deshabilitar las migraciones desde la configuración de Django en lugar de pytest-django
about 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda