2014-01-03 5 views
9

В django 1.5 и более ранних версиях, запущенный python manage.py test, по умолчанию запускал все тесты в проекте (в том числе все в django.contrib). После версии 1.6 поведение по умолчанию - это запуск всех тестов в текущем каталоге.Выполнение всех тестов post django 1.6

Каков наилучший способ (v 1.6) выполнить все тесты, либо с помощью тестов django.contrib, либо без них?

ответ

15

changed the default test runner Джанго 1,6 до:

TEST_RUNNER = 'django.test.runner.DiscoverRunner' 

Вы можете получить старое поведение назад, добавив к вашему settings.py:

TEST_RUNNER = 'django.test.simple.DjangoTestSuiteRunner' 

Как объяснены в примечаниях к выпуску:

Предыдущий бегун (django.test.simple.DjangoTestSuiteRunner) нашел tes ts только в модулях models.py и tests.py пакета Python в INSTALLED_APPS.

Новый бегун (django.test.runner.DiscoverRunner) использует функции обнаружения тестов, встроенные в unittest2 (версия unittest в стандартной библиотеке Python 2.7+ и в комплекте с Django). При обнаружении теста тесты могут быть расположены в любом модуле, имя которого соответствует шаблону test * .py.

Новый бегуна ожидает список пунктирных путей модулей, где испытания должны быть обнаружены, так что вы можете также запустить тесты из django contrib так:

python manage.py test myproject django.contrib path.to.someotherapp 

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

Также обратите внимание, что обычно не требуется запускать тесты с django.contrib, так как они не тестируют ваше приложение, а скорее дистрибутив Django. Django поставляется с еще большим количеством тестов, которые не выполняются ни бегуном.

+0

Хорошо ... позвольте мне немного измените вопрос. Каков наилучший способ запуска всех тестов с использованием нового тестового бегуна? – Luke

+0

@ Luke вы можете передать 'django.contrib' в качестве аргумента тестовой команды, как объясняется в моем обновленном ответе. Но это не будет запускать ** все ** приложения. –

+0

Спасибо, Николас. Хотя то, что я пытался решить с моим вопросом, - как запустить все тесты из всех моих приложений? запуск 'python manage.py test myproject' продолжает запускать для меня 0 тестов. Это только моя конфигурация? – Luke

0

Жаль, что Django решил игнорировать пользовательские приложения в INSTALLED_APPS, которые не находятся в дереве проекта. См. Это сообщение https://groups.google.com/forum/#!topic/django-users/gGfVhfrfE10 за их рассуждения.

Мое реальное дело, конечно, не относится к трем упомянутым вариантам использования (большой сюрприз!): У нас есть сайт, который мы развертываем с помощью другой коллекции тесно связанных пользовательских приложений для клиента/группы клиентов. Мы не делаем хотим, чтобы эти приложения были вложены под деревом проекта, потому что каждый из них находится в своем собственном репозитории git. В прошлом мы использовали git-подмодули, поддельные подмодули и поддеревья; у всех были проблемы в нашей установке. С другой стороны, каждое приложение как собственный пакет на том же уровне, что и сайт, удовлетворяет большинству наших требований.

Конечно, у каждого приложения есть свои собственные тесты, но я хотел бы иметь возможность запускать полный набор тестов (включая сайт и все пользовательские приложения) для каждого конкретного сайта, созданного по-разному.

Наш обходной путь заключается в следующем:

В settings/test.py у меня есть:

ATA_BLACKLIST = ['scary_mod1', 'scary_mod2'] 
ADD_TEST_APPS = [i for i in INSTALLED_APPS 
       if '.' not in i and i not in ATA_BLACKLIST] 
ATA_STR = " ".join(ADD_TEST_APPS) 

У меня есть run_tests.sh сценарий на высшем уровне, который выглядит более или менее, как это:

#!/bin/bash 

MYDIR=`dirname $0` 
cd $MYDIR 
DJANGO_SETTINGS_MODULE=kmxng.settings.test 
ATA_STR=`python -c "from django.conf import settings; print settings.ATA_STR"` 
coverage run --omit "*lib/python*" ./manage.py test . $ATA_STR 
coverage report 

Короче говоря, в моих тестовых настройках я генерирую список дополнительных модулей, которые необходимо добавить к тестированию. Я вызываю команду django test с этим списком в дополнение к по умолчанию ..

(я взглянуть на переопределение DiscoverRunner -.. Она имеет относительно длинный build_suite метод, который может быть преодолено Работа вокруг выше, является менее инвазивным вариант)

 Смежные вопросы

  • Нет связанных вопросов^_^