2011-06-06 1 views
14

Мне сложно настроить настройку настройки тестовой базы данных. Я хотел бы добиться следующего:Тест Django для использования существующей базы данных

  • Наборы тестов нужно использовать существующую базу данных
  • Тестовый набор не должен удалить или восстановить базу данных вместо загрузки данных из MySQL дамп
  • Поскольку дб заполняется из свалки, не светильники не должны быть загружены
  • по окончании испытаний базы данных не должны быть уничтожены

Я имею трудное время получить testsuiterunner для создания обхода.

+0

Каким образом вы используете существующую базу данных, если вы загружаете данные из дампа sql? Я бы предложил загрузить дамп, создать светильники и использовать обычный подход к тестированию. – shanyu

+2

есть много данных, и загрузка с дампа происходит быстрее, чем загрузка с приборов – pyeleven

+0

Так что речь идет не об использовании существующей базы данных. Вы на 100% уверены, что вам нужно провести тестирование, используя полные данные? Может ли образец быть достаточным для тестирования? – shanyu

ответ

0

Вам необходимо предоставить собственный тестовый бегун.

Биты, которые вы заинтересованы в переопределении по умолчанию django.test.runner.DiscoverRunner, - это методы DiscoverRunner.setup_databases и DiscoverRunner.teardown_databases. Эти два метода связаны с созданием и уничтожением тестовых баз данных и выполняются только один раз. Вы захотите предоставить параметры проекта, определенные по умолчанию, которые используют существующую тестовую базу данных по умолчанию и переопределяют их так, чтобы данные дампа загружались и база данных тестирования не была уничтожена.

В зависимости от размера и содержимого дампа безопасной ставкой может быть просто создание подпроцесса, который будет передавать дамп в интерфейс командной строки SQL базы данных, иначе вы могли бы получить курсор и execute queries directly.

Если вы ищете, чтобы избавиться от арматуры нагрузки полностью, вы можете предоставить тестовый пример пользовательской базы, которая простирается Джанго по умолчанию django.test.testcases.TestCase с TestCase._fixutre_setup и TestCase._fixutre_teardown методов переопределено быть Ноопом.

Caveat emptor: этот бегун не сможет облегчить тесты ни на чем, кроме источников вашего приложения. Можно настроить бегун для создания конкретного псевдонима для подключения к существующей базе данных и загрузки дампа, а затем предоставить собственный тестовый пример, который переопределяет TestCase._database_names, чтобы указать на его псевдоним.

3

Это TEST_RUNNER работает в Django 1.3

from django.test.simple import DjangoTestSuiteRunner as TestRunner 

class DjangoTestSuiteRunner(TestRunner): 
    def setup_databases(self, **kwargs): 
     pass 

    def teardown_databases(self, old_config, **kwargs): 
     pass 
2

Перенесемся в 2016 году, и способность сохранять базу данных между тестами было построено в Джанго. Он доступен в форме --keep flag для управления. 1

Новое в Django 1.8. Сохраняет тестовую базу данных между тестовыми запусками. У этого есть преимущество пропускать действия create и destroy , что может значительно сократить время на запуск тестов, особенно в большом наборе тестов. Если тестовая база данных не существует, она будет , созданной при первом запуске, а затем сохраненной для каждого последующего запуска. Любые непримененные миграции также будут применены к тестовой базе данных перед запуском набора тестов.

Это в значительной степени соответствует всем критериям, указанным в ваших вопросах. На самом деле это еще один шаг вперед. Нет необходимости импортировать дамп перед каждым запуском.