Las pruebas unitarias de Django tardan mucho tiempo en crear una base de datos de pruebas

Resumen

Use pytest !

Operaciones

1. pip install pytest-django
2. pytest --nomigrations en lugar de ./manage.py test

Resultado

• ./manage.py test cuesta 2 min 11.86 seg
• pytest --nomigrations cuesta 2.18 seg

Consejos

• Puede crear un archivo llamado pytest.ini en el directorio raíz de su proyecto, y especificar las opciones predeterminadas de la línea de comandos y/o la configuración de Django allí.

  # content of pytest.ini
  [pytest]
  addopts = --nomigrations
  DJANGO_SETTINGS_MODULE = yourproject.settings
  

  Ahora puedes simplemente ejecutar prueba con pytest y te ahorra un poco de escritura.

• Puede acelerar las pruebas posteriores aún más agregando --reuse-db a las opciones predeterminadas de la línea de comandos.

  [pytest]
  addopts = --nomigrations --reuse-db
  

  Sin embargo, tan pronto como se cambie su modelo de base de datos, debe ejecutar pytest --create-db una vez para forzar la recreación de la base de datos de prueba.

• Si necesita habilitar gevent monkey patching durante las pruebas, puede crear un archivo llamado pytest en la raíz de su proyecto directorio con el siguiente contenido, envíe el bit de ejecución a él (chmod +x pytest) y ejecute ./pytest para probar en lugar de pytest:

  #!/usr/bin/env python
  # -*- coding: utf-8 -*-
  # content of pytest
  from gevent import monkey
  
  monkey.patch_all()
  
  import os
  
  os.environ.setdefault("DJANGO_SETTINGS_MODULE", "yourproject.settings")
  
  from django.db import connection
  
  connection.allow_thread_sharing = True
  
  import re
  import sys
  
  from pytest import main
  
  if __name__ == '__main__':
      sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
      sys.exit(main())
  

  Puede crear un archivo test_gevent.py para probar si el parche de gevent monkey es exitoso:

  # -*- coding: utf-8 -*-
  # content of test_gevent.py
  import time
  from django.test import TestCase
  from django.db import connection
  import gevent
  
  
  def f(n):
      cur = connection.cursor()
      cur.execute("SELECT SLEEP(%s)", (n,))
      cur.execute("SELECT %s", (n,))
      cur.fetchall()
      connection.close()
  
  
  class GeventTestCase(TestCase):
      longMessage = True
  
      def test_gevent_spawn(self):
          timer = time.time()
          d1, d2, d3 = 1, 2, 3
          t1 = gevent.spawn(f, d1)
          t2 = gevent.spawn(f, d2)
          t3 = gevent.spawn(f, d3)
          gevent.joinall([t1, t2, t3])
          cost = time.time() - timer
          self.assertAlmostEqual(cost, max(d1, d2, d3), delta=1.0,
                                 msg='gevent spawn not working as expected')
  

Referencias

• pytest-django documentation
• documentación de pytest

Use ./manage.py probar ke keepdb cuando no hay cambios en los archivos de migración

La inicialización de la base de datos toma demasiado tiempo...

Tengo un proyecto con aproximadamente el mismo número de modelos/tablas (alrededor de 77), y aproximadamente 350 pruebas y toma 1 minuto en total para ejecutar todo. Deving en una máquina vagabunda con 2 cpu asignadas y 2 GB de ram. También uso py.prueba con el plugin pytest-xdist para ejecutar múltiples pruebas en paralelo.

Otra cosa que puede hacer es decirle a django que reutilice la base de datos de prueba y solo vuelva a crearla cuando tenga cambios de esquema. También tú puede usar SQLite para que las pruebas usen una base de datos en memoria. Ambos enfoques explicados aquí: https://docs.djangoproject.com/en/dev/topics/testing/overview/#the-test-database

EDITAR: En caso de que ninguna de las opciones anteriores funcione, una opción más es hacer que sus pruebas unitarias hereden de django SimpleTestCase o usar un ejecutor de pruebas personalizado que no cree una base de datos como se explica en esta respuesta: pruebas unitarias de django sin una db.

Entonces puedes simplemente simula llamadas de django a la base de datos usando una biblioteca como esta (que admito que escribí): https://github.com/stphivos/django-mock-queries

De esta manera puede ejecutar sus pruebas unitarias localmente rápido y dejar que su servidor CI se preocupe por ejecutar pruebas de integración que requieren una base de datos, antes de fusionar su código en alguna rama estable dev/master que no sea la de producción.