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

• Первый критерий – это уверенность. Никогда не удаляйте тест, если в результате этого снизится ваша уверенность в поведении системы.

• Второй критерий – это коммуникация. Если у вас есть два теста, которые тестируют один и тот же участок кода, однако читателем эти тесты рассматриваются как два различных сценария, сохраните оба теста.

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

Как язык программирования и среда разработки влияют на TDD?

Попробуйте использовать подход TDD в среде Smalltalk с браузером Refactoring Browser. Теперь попробуйте работать в среде C++ с редактором vi. Почувствуйте разницу.

В языках программирования и средах разработки, в которых цикл TDD выполняется сложнее (тест – компиляция – запуск – рефакторинг), возникает тенденция двигаться вперед более длинными шагами:

• каждый тест охватывает больший объем кода;

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

Приводит ли это к замедлению разработки, или, наоборот, разработка ускоряется?

В языках программирования и средах, в которых проще выполнить цикл TDD, у вас будет возникать желание больше экспериментировать с кодом. Позволит ли это двигаться быстрее и формировать лучшие решения, или вам кажется, что лучше тратить время на дополнительные размышления о дизайне?

Можно ли использовать TDD для разработки крупномасштабных систем?

Позволяет ли методика TDD разрабатывать крупномасштабные программные проекты? Какие новые типы тестов вам потребуется написать? Какие новые шаблоны рефакторинга могут потребоваться?

Самой крупной программной системой, целиком и полностью разработанной в стиле TDD, в создании которой я принимал участие, является система LifeWare (www.lifeware.ch). Работа над системой велась в течение 4 лет. Объем работ оценивается в 40 человеко-лет. На текущий момент система включает в себя 250 000 строк функционального и 250 000 строк тестирующего кода (на языке Smalltalk). Набор тестов системы включает в себя 4000 тестов, для выполнения которых требуется 20 минут. Полный набор тестов запускается несколько раз каждый день. Реализованный в системе огромный объем функциональности, похоже, никак не снижает эффективности TDD. Избавляясь от дублирования, вы стараетесь создать большое количество маленьких объектов, которые можно тестировать изолированно друг от друга вне зависимости от размера приложения.

Можно ли осуществлять разработку через тестирование на уровне приложения?

Если мы будем выполнять разработку, используя только внутренние программистские тесты (их называют тестами модулей – unit tests, – хотя они не вполне соответствуют этому определению), мы рискуем столкнуться с проблемой: полученная в результате этого система может оказаться не совсем тем или, что хуже, совсем не тем, что хочет получить пользователь. Программист будет работать над программой, которая, по его мнению, должна быть полезна, однако у пользователя может оказаться совершенно другое мнение. Чтобы решить проблему, можно разработать набор тестов на уровне приложения. Разработкой этих тестов должны заниматься сами пользователи (при поддержке программистов). Написанные пользователями тесты должны точно определять, что именно должна делать разрабатываемая система. Такой стиль можно назвать разработкой через тестирование на уровне приложения (ATDD, Application Test-Driven Development).

Встает техническая проблема: как написать и запустить тест для функциональности, которая еще не существует? Мне кажется, что всегда можно найти способ решения этой проблемы. Например, можно разработать интерпретатор, который будет вежливо сигнализировать о том, что обнаружен тест, выполнить который на данный момент невозможно по причине отсутствия в системе необходимых возможностей.

Существует также социальная проблема. У пользователей (на самом деле я имею в виду команду, в состав которой входят пользователи) появляется новая обязанность: разработка тестов. Процедура разработки тестов уровня приложения требует добавления дополнительного этапа в цикл работы над продуктом, – а именно, разработка пользовательских тестов выполняется перед началом реализации очередного объема функциональности. Организации часто сопротивляются подобному сдвигу ответственности. Новый этап требует координированных усилий множества членов команды, то есть перед тем, как приступить непосредственно к разработке кода, члены команды вынуждены потратить время на разработку пользовательских тестов.