Django Unit Testing занимает очень много времени для создания тестовой базы данных

Ответ 1

Окончательное решение, которое решает мою проблему, состоит в том, чтобы заставить Django отключить миграцию во время тестирования, что можно сделать из настроек, подобных этой

TESTING = 'test' in sys.argv[1:]
if TESTING:
    print('=========================')
    print('In TEST Mode - Disableling Migrations')
    print('=========================')

    class DisableMigrations(object):

        def __contains__(self, item):
            return True

        def __getitem__(self, item):
            return "notmigrations"

    MIGRATION_MODULES = DisableMigrations()

или используйте https://pypi.python.org/pypi/django-test-without-migrations

Весь мой тест теперь занимает около 1 минуты, а маленькое приложение - 5 секунд.

В моем случае миграции не нужны для тестирования, так как я обновляю тесты во время миграции и не использую миграции для добавления данных. Это не будет работать для всех

Ответ 2

Резюме

Используйте pytest!

Операции

• pip install pytest-django
• pytest --nomigrations вместо ./manage.py test

Результат

• ./manage.py test стоит 2 мин. 11,86 сек.
• pytest --nomigrations стоит 2,18 секунды

Советы

• Вы можете создать файл с именем pytest.ini в корневом каталоге проекта и указать параметры командной строки по умолчанию и/или настройки Django.

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

  Теперь вы можете просто запускать тесты с помощью pytest и немного печатать.

• Вы также можете ускорить последующие тесты, добавив --reuse-db к параметрам командной строки по умолчанию.

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

  Однако, как только ваша модель базы данных будет изменена, вы должны запустить pytest --create-db один раз, чтобы принудительное повторное создание тестовой базы данных.

• Если вам нужно включить gevent monkey patching во время тестирования, вы можете создать файл с именем pytest в корневом каталоге проекта со следующим содержимым, приложите к нему бит выполнения (chmod +x pytest) и запустите ./pytest для тестирования вместо 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())
  

  Вы можете создать файл test_gevent.py для проверки успешности исправления обезьяны gevent:

  # -*- 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')
  

Ссылки

• документация pytest-django
• документация pytest

Ответ 3

используйте тест./manage.py --keepdb, если в файлах миграции нет изменений

Ответ 4

Инициализация базы данных действительно занимает слишком много времени...

У меня есть проект с примерно таким же количеством моделей/таблиц (около 77) и примерно 350 тестов и занимает 1 минуту, чтобы запустить все. Девять в бродячей машине с выделенным 2 cpus и 2 ГБ оперативной памяти. Также я использую py.test с плагином pytest-xdist для параллельной параллельной работы нескольких тестов.

Еще одна вещь, которую вы можете сделать, это сказать, что django повторно использует тестовую базу данных и только повторно создает ее при изменении схемы. Также вы можете использовать SQLite, чтобы тесты использовали базу данных в памяти. Оба подхода объясняются здесь: https://docs.djangoproject.com/en/dev/topics/testing/overview/#the-test-database

РЕДАКТИРОВАТЬ. Если ни одна из вышеперечисленных опций не работает, еще один вариант заключается в том, чтобы ваши модульные тесты наследовали от django SimpleTestCase или использовали пользовательский тестовый бегун, который не создает базу данных, как описано в этот ответ здесь: модульные тесты django без db.

Затем вы можете просто высмеять вызовы django в базу данных, используя библиотеку, подобную этой (которая, как я понимаю): https://github.com/stphivos/django-mock-queries

Таким образом, вы можете быстро запускать свои модульные тесты и позволить вашему CI-серверу беспокоиться о выполнении интеграционных тестов, требующих базы данных, до слияния вашего кода с какой-то стабильной ветвью dev/master, которая не является производственной.