Идеальный программист. Как стать профессионалом разработки ПО полностью

На рынке имеются коммерческие программы, которые выглядят неплохо. Я видел, как мои клиенты пользуются ими, но пока не имел возможности поработать лично. Не имею ничего против таких инструментов – при условии, что список задач остается небольшим и легко управляемым. Когда средства отслеживания задач вынуждены работать со списками из тысяч позиций, само слово «отслеживание» теряет смысл. Список текущих задач превращается в «свалку текущих задач» (и часто пахнет соответствующим образом).

В последнее время для обеспечения непрерывной сборки я использую Jenkins. Система нетребовательна, проста, а работа с ней не требует длительной подготовки. Вы загружаете программу, запускаете ее, проводите несложную настройку конфигурации – а дальше все работает. Очень удобно.

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

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

В проекте 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 могут автоматически идентифицировать тесты, а вы избавляетесь от хлопот с подготовкой тестов.

Инструменты этой категории предназначены для тестирования компонентов на уровне API. Их роль – определение поведения компонента на языке, понятном для бизнеса и специалистов по контролю качества. В идеале бизнес-аналитики и специалисты по контролю качества должны писать спецификации с использованием данных инструментов.