Не забывайте запускать тесты перед фиксацией - PullRequest
6 голосов
/ 16 августа 2010

У нас есть приличный набор модульных тестов для нашего кода, и эти модульные тесты выполняются менее чем за 2 минуты.Мы также используем TeamCity для выполнения сборки и запуска тестов после каждой регистрации. Однако у нас по-прежнему возникают проблемы, когда разработчик «забывает» запускать все тесты перед фиксацией, что приводит к сбою TeamCity, который, если эта проверка была выполнена в 18:00может остаться сломанным в течение ночи.

«Забывает» - это общий термин, есть пара других распространенных причин, по которым даже незапланированное выполнение тестов может привести к сбою TeamCity.Такие как.

-> Разработчик проверяет только некоторые измененные файлы в своем рабочем пространстве.
-> Файл был изменен вне затмения, так что перспектива синхронизации команды eclipse не определяет его как грязный.

Как вы справляетесь с этим в вашей организации?

Мы думаем о введении «процедуры регистрации» для разработчиков, которая будет автоматизированным инструментом, который будет автоматически запускать все модульные тесты и затем фиксировать все «грязные» файлы в вашем рабочем пространстве.Был ли у вас опыт такого процесса?Вам известны какие-либо инструменты, которые могут облегчить этот процесс?Наша среда разработки - это Python, использующий плагин Eclipse для PyDev.

Ответы [ 5 ]

6 голосов
/ 16 августа 2010

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

4 голосов
/ 16 августа 2010

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

Да, вы можете улучшить имеющиеся системы, но они не подойдут кому-то, кто думает о последствиях своего коммита и тестирует его до того, как он нажмет коммит.

3 голосов
/ 16 августа 2010

TeamCity имеет некоторую поддержку предварительно проверенный коммит ; если ваша команда разработчиков использует поддерживаемую IDE, вы можете посмотреть на это.

В моей компании мы не слишком беспокоимся об этом - наш шаблон выглядит примерно так.

(a) каждый разработчик имеет свою собственную конфигурацию проекта в TeamCity, корни которой указывают на свою собственную песочницу. Здесь им разрешено делать все, что им нравится.

(b) команда разработчиков имеет интегрированную изолированную программную среду, в которую вносятся все изменения. Проект инкапсулирует конфигурации, которые отслеживают эту ветвь в системе контроля версий. Dev Leads может придумать правила здесь, но это правило почти всегда "оно должно оставаться зеленым". Я бы посмотрел точный процент чистых сборок - это не идеальная запись, но достаточно высокая, чтобы у меня никогда не было соблазна настаивать на том, чтобы разработчики были более дисциплинированными в отношении выполнения тестов.

(c) фактическая доставка происходит из основного потока, который должен оставаться зеленым (тм). Ответственный за разработку отвечает за предоставление четкого снимка интеграции в основной поток по четко определенному расписанию. Этот проект является тем, который на самом деле генерирует установщики, которые поставляются для тестирования, биты, которые идут на условное депонирование и т. Д.

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

3 голосов
/ 16 августа 2010

Для Mercurial вы можете использовать хуки, которые будут запускать тесты и позволят только нажать на успех.Но для этого может потребоваться много времени (но разработчику все равно придется запускать эти тесты).

Или вы можете просто иметь собственный набор сценариев bash, который будет запускать тестирование и только затем запускать команду commit.Например, для django и svn commit это может выглядеть так просто:

./manage.py test && svn commit $@

Или есть другой способ: если кто-то фиксирует код, который не проходит тест, он платит некоторую сумму.Вскоре люди начнут проверять, потому что им не понравится идея платить деньги; -)

0 голосов
/ 08 декабря 2015

Для мерзавца вы можете: http://francoisgaudin.com/2011/02/16/run-django-tests-automatically-before-committing-on-git/

Автоматический запуск тестов Django перед фиксацией в Git

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

Однако автоматически запускать тесты перед каждым совершить. В .git / hooks / pre-commit введите:

python manage.py 
test exit $?

затем chmod 755 этот файл и все готово. Я действительно люблю мерзавца: -)

Не забудьте указать исходные данные перед совершением.

Обратите внимание, что тесты выполняются на вашем рабочем дереве, а не на коммите сама по себе, так что если вы фиксируете только часть вашего рабочего дерева, он может потерпеть неудачу пока ваш коммит проходит тесты.

...