Экстремальное программирование. Разработка через тестирование. Кент Бек

Чтение книги онлайн.

      Теперь можно пометить первый тест как завершенный. Далее мы позаботимся о тех странных побочных эффектах; но сначала давайте подведем итоги. Мы сделали следующее:

      • создали список тестов, которые – мы знаем – нам понадобятся;

      • с помощью фрагмента кода описали, какой мы хотим видеть нашу операцию;

      • временно проигнорировали особенности среды тестирования JUnit;

      • заставили тесты компилироваться, написав соответствующие заготовки;

      • заставили тесты работать, использовав сомнительные приемы;

      • слегка улучшили работающий код, заменив константы переменными;

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

      2. Вырождающиеся объекты

      Обычный цикл разработки на основе тестирования состоит из следующих этапов:

      1. Напишите тест. Представьте, как будет реализована в коде воображаемая вами операция. Продумав ее интерфейс, опишите все элементы, которые, как вам кажется, понадобятся.

      2. Заставьте тест работать. Первоочередная задача – получить зеленую полоску. Если напрашивается простое и элегантное решение, используйте его. Если же на реализацию такого решения потребуется время, отложите его. Просто отметьте, что к нему нужно вернуться, когда будет решена основная задача – быстро получить зеленый индикатор. Такой подход довольно неприятен для опытных разработчиков (в эстетическом плане), ведь они следуют только правилам хорошей разработки. Но зеленая полоска прощает все грехи, правда, всего лишь на мгновение.

      3. Улучшите решение. Теперь, когда система работает, избавьтесь от прошлых огрехов и вернитесь на путь истинной разработки. Устраните дублирование, которое вы внесли, и быстро сделайте так, чтобы полоска снова стала зеленой.

      Наша цель – чистый код, который работает (отдельное спасибо Рону Джеффризу за этот слоган). Иногда такой код не по силам даже самым лучшим программистам, и почти всегда он не достижим для большинства программистов (вроде меня). Разделяй и властвуй, приятель, – в этом весь смысл! Сначала мы напишем код, «который работает», после чего создадим «чистый код». Такой подход противоречит модели разработки на основе архитектуры, в которой вы сначала пишете «чистый код», а потом мучаетесь, пытаясь интегрировать в проект код, «который работает».