Комментарии 16
Кто еще прочитал How to NO continuous integration?
А я в свое время TeamCity не осилил, что-то coverage не получилось настроить, хотя Jenkins'ом сейчас доволен.
Спасибо за топик!
Спасибо за топик!
Здесь я бы ограничил 1. Я подозреваю что в БД при одновременном запуске нескольких тестов могут начнаться конфликты данных и билды запросто не пройдут.
Да, но я не стал углубляться в тонкости правильного конфигурирования всех параметров (тем более что у меня — я единственный коммитер, а писал я мануал со своей ситуации), портянка и так длинная. Целью было минимально настроить и поднять все компоненты чтобы автоматом собиралось и тестилось. Думаю про нюансы настройки можно накропать ещё не один такой рулон писанины…
БД для тестов лучше всего указать in-memory sqlite, это гораздо быстрее
Мне кажется это совсем уж спорный вопрос, особенно, если учитывать, что мы тут даже виртуальное окружение проверяем на работоспособность — мало ли чего там в реализации не так. Вдруг оно будет пахать в памяти, а на планируемом мускуле не полетит? Миграции не промигрируются?
Понятно что быстрее, но я лично от греха подальше пускаю тесты в той же СУБД что будет на боевой системе…
Понятно что быстрее, но я лично от греха подальше пускаю тесты в той же СУБД что будет на боевой системе…
Для тех кому пока кажеться, что решение вроде TeamCity/Jenkins слишком громоздки и неоправданы для вашего не очень большого проекта — рекомендую посмотреть на nosy. Это автоматическая запускалка тестов через nose, которая перезапускает все тесты при измении файлов проекта. Очень удобно запускать в соседнем окне и мгновенно видеть прогрес после очередного сохранения текущего файла.
У nose очень хитрый загрузчик модулей с тестами, и в результате возможны ситуации когда стандартный ./manage.py test работает, под вебсервером работает, а nose тесты падают.
В частности у меня была проблемы со всяческими @register декораторами, и десериализацией объектов из-за того что под nose в одном случае объект получался из project.app.module, а в другом просто app.module
Понаступав на подобные грабли, я в итоге и написал django-jenkins, который загружает тесты в так же и запускает в том же порядке как и стандартный django test
ИМХО, т.к формат выходных файлов одинаковый, django-jenkins можно и с Teamcity вероятно так же просто использовать.
В частности у меня была проблемы со всяческими @register декораторами, и десериализацией объектов из-за того что под nose в одном случае объект получался из project.app.module, а в другом просто app.module
Понаступав на подобные грабли, я в итоге и написал django-jenkins, который загружает тесты в так же и запускает в том же порядке как и стандартный django test
ИМХО, т.к формат выходных файлов одинаковый, django-jenkins можно и с Teamcity вероятно так же просто использовать.
И вот еще один вечный баг, c созданием таблиц для моделей в tests.py в django-nose — github.com/jbalogh/django-nose/issues/15
К статье+ надо добавить в settings.py << TEST_RUNNER = 'django_nose.NoseTestSuiteRunner'.
Если после manage.py test не будет работать.
Если после manage.py test не будет работать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HowTo: continuous integration проекта на Django с помощью TeamCity