ее, проводите несложную настройку конфигурации – а дальше все
работает. Очень удобно.
Мой подход к непрерывной сборке прост: свяжите ее с системой
управления исходным кодом. Каждый раз, когда в базе регистрируется
измененный код, должна выполняться непрерывная сборка, отчет о
результатах которой выдается группе.
Группа
просто обязана следить за тем, чтобы сборка всегда
проходила успешно. Если сборка не проходит, это должно стать
тревожным сигналом, а группа должна
немедленно собраться для
решения проблемы. Ни при каких условиях недействующая сборка не
должна существовать более суток.
В проекте FitNesse я требую, чтобы каждый разработчик выполнял
сценарий непрерывной сборки перед регистрацией своих изменений.
Сборка занимает менее 5 минут, так что она необременительна. Если
в ходе сборки обнаруживаются проблемы, разработчики устраняют их
до регистрации. Таким образом, автоматическая сборка редко
сталкивается с какими-либо проблемами. Чаще всего проблемы при
автоматической сборке возникают из-за настроек рабочей среды,
поскольку моя среда автоматической сборки
значительно отличается
от сред разработчиков.
Инструменты модульного тестирования
Для каждого языка существуют свои специализированные средства
модульного тестирования. Лично я использую
JUnit
для Java,
rspec
для
Ruby,
NUnit
для. Net,
Midje
для Clojure и
CppUTest
для C и C++.
Впрочем, какой бы инструмент модульного тестирования вы ни
выбрали, все они должны обладать набором базовых свойств и
функций.
1. Тесты должны запускаться легко и быстро. Не
важно, как
именно это делается – при помощи плагинов IDE или простых утилит
командной строки; главное, чтобы разработчики
могли запускать эти
тесты по своему усмотрению. Команда запуска должна быть
тривиально простой. Например, я запускаю свои тесты CppUTest в
TextMate простым нажатием клавиш
command+M
. Я
связал эту
комбинацию с запуском
makefile
, который автоматически выполняет
тесты и выводит короткий однострочный отчет в том случае, если все
тесты прошли успешно. IntelliJ поддерживает
JUnit
и
rspec
, поэтому от
меня требуется лишь нажать кнопку. Для выполнения
NUnit
я
использую плагин Resharper.
2. Программа должна выдавать
четкий визуальный признак
прохождения/непрохождения теста. Не важно, будет ли это зеленая
полоса на графическом экране или консольное сообщение «Все тесты
прошли». Суть в том, чтобы вы могли быстро и однозначно
определить, что все тесты прошли. Если для определения результата
тестирования приходится читать многострочный отчет или, того хуже,
сравнивать выходные данные двух файлов, – условие не выполнено.
3. Программа должна выдавать четкий визуальный признак
прогресса. Не важно, будет ли это графический индикатор или строка
постепенно появляющихся точек – главное, чтобы пользователь видел,
что процесс идет, а тестирование не остановилось и не прервалось.
4. Программа должна препятствовать взаимодействию между
отдельными тестовыми сценариями.
JUnit
решает эту проблему,
создавая новый экземпляр тестового класса для каждого тестового
метода; таким образом предотвращается
использование переменных
экземпляров для взаимодействия между тестами. Другие инструменты
запускают тестовые методы в случайном порядке, чтобы исключить
возможную зависимость от конкретного порядка выполнения тестов.
Независимо от конкретного выбора механизма, программа должна
принять меры к обеспечению независимости тестов. Зависимые тесты
–
опасная ловушка, которую необходимо избегать.
5. Программа должна по возможности упрощать написание тестов.
Например,
JUnit
предоставляет удобный API для проверки условий
(assertions), а также использует рефлексию и атрибуты Java для того,
чтобы отличать тестовые функции от обычных. В результате хорошие
IDE могут автоматически идентифицировать тесты, а вы избавляетесь
от хлопот с подготовкой тестов.
Do'stlaringiz bilan baham: