след ует
написать тест и запустить его, чтобы убед иться, что он не
работает. Вернувшись к код у, вы сразу увид ите место, откуд а можно
прод олжить. Вы получаете хорошо заметную заклад ку, которая помогает
вам вспомнить, о чем вы д умали. Оставленный
неработающим тест
д олжен быть про ст в реализации, благод аря чему вы сможете быстро
выйти на прежний маршрут и прод олжить д вижение к побед е.
Сначала я д умал, что о ставленный нед од еланным тест буд ет
д ействовать мне на нервы. Од нако нет. Вед ь вся программа в целом еще
д алека от завершения, од ин сломанный тест не сд елает ее менее
завершенной, и я отлично знаю об этом.
Возможно сть быстро
во сстановить общий ход разработки спустя несколько нед ель про стоя
стоит того, чтобы немножко по ступиться принципами и о ставить
работу, имея перед глазами красную поло су.
Чистый выпускаемый код (Clean Check-in)
Как след ует завершить сеанс программирования, если вы
программируете в со ставе команд ы? Все ваши тесты д олжны работать.
Я противоречу сам себе? Да.
Бубба Уитман (Bubba Whitman), брат Уолта –
портового грузчика
Когд а вы работаете над код ом не од ин, а вместе с вашими
коллегами, ситуация полно стью меняется. Когд а вы возвращаетесь к
работе
над код ом, над которым помимо вас работают еще несколько
человек, вы не можете сказать точно, что именно произошло с код ом с
того момента, как вы вид ели его по след ний раз. По этой причине,
прежд е чем выпускать разрабатываемый вами код , убед итесь,
что все
тесты выполняются успешно. (Это напоминает правило изоляции
тестов, в соответствии с которым кажд ый тест гарантированно
о ставляет систему в хорошем известном со стоянии. Это правило можно
применить и в отношении программистов, которые поочеред но
интегрируют свой код в систему, кажд ый раз проверяя, о стается система
в хорошем со стоянии или нет.)
Набор тестов, которые вы запускаете в ход е интеграции, может
быть существенно
объемнее набора тестов, который вы запускаете
кажд ую минуту в процессе разработки функционально сти. (До того
времени, пока это не станет слишком утомительным, я рекоменд ую вам
по стоянно запускать полный набор тестов.) Что д елать, если при
попытке интеграции вы обнаружили, что од ин тест из полного набора
завершается неуд ачей?
Самое про стое правило: отбро сьте прод еланную работу и начните
все заново. Сломанный сигнализирует, что вы не облад аете д о статочным
запасом знаний, чтобы запрограммировать то, над чем вы работаете.
Если команд а буд ет д ействовать в соответствии с этим правилом, у ее
членов появится тенд енция выполнять интеграцию более часто, так как
тот, кто успеет приступить к интеграции раньше д ругих, не рискует
потерять прод еланную работу. По всей вид имо сти, частая интеграция и
проверка – это неплохая практика.
Существует д ругой, менее строгий под ход : вы можете исправить
д ефект и попробовать снова выполнить интеграцию. Од нако не
забывайте, что вы не д олжны слишком д олго занимать интеграционные
ресурсы: если вы не можете решить проблему в течение нескольких
минут, откажитесь от ид еи интеграции и начните работу заново. Об
этом
можно не говорить, но я все-таки скажу, что комментирование
од ного теста с целью заставить работать весь набор строго запрещается
и д олжно привод ить к самым серьезным карательным санкциям.