Читаем Постигая Agile полностью

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

Однако можно обсуждать этот вопрос на более глубоком уровне. Одна из причин, по которой разработчики (особенно имеющие большой опыт использования Agile и ХР) поднимают этот вопрос, заключается в том, что существуют команды, воспринимающие TDD не только как инструмент, но и как разновидность верования. Они сосредоточиваются на тестах как на конечной цели, а не как на средстве для создания лучшего программного обеспечения. Такие команды попадают в платформенную ловушку, затрачивая много времени на создание обширных и сложных платформ для тестирования. Разработка через тестирование предполагает помощь команде в сохранении простого исходного кода. Но когда он становится сложным, это значит, что-то пошло не так[72].

Те, кто заявляет, что «TDD умерла», считают, будто ХР-практики (особенно TDD и парное программирование) создают значительное эмоциональное сопротивление у команд, которые недостаточно знакомы с ними.

Команда, использующая ХР, не считает своей целью написание модульных тестов, так же как водопадные команды не рассматривают в качестве цели создание спецификаций. Главное – собрать работающее программное обеспечение, а TDD и спецификации лишь средства для достижения этой цели.

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

В главах 6 и 7 мы использовали термины «разработка через тестирование» и «разработка с опережающим написанием тестов» как синонимы. В течение многих лет их именно так и рассматривали, и мы решили, что для понимания концепции это упрощение было допустимо. Но некоторые люди рассматривают разработку с опережающим написанием тестов лишь как создание сначала тестов, а потом кода, в то время как TDD подразумевает более широкий подход к проектированию.

Надо ли писать тесты первыми, чтобы получить хорошо спроектированный код? Конечно, нет – многие команды делают прекрасный код без использования TDD. Но является ли TDD ценным инструментом для сборки хорошо продуманного кода? Безусловно. Если вы еще не применяли TDD, то без труда придумаете гипотетические причины не делать этого («Мне нравится делать наброски того, что я создаю, и видеть, как оно скрепляется вместе. В противном случае мне незачем писать тесты, поэтому ясно, что при применении TDD мне придется идти на компромисс!»)

Но дело в том, что многие команды используют TDD в строгом соответствии с методикой[73], а многие из этих гипотетических причин исчезают, когда вы делаете серьезные попытки применить эту практику.

Полезно заглянуть в статью, с которой началась большая дискуссия на тему, мертва ли TDD, и не пропустить ответ Кента Бека[74], опубликованный в Facebook. В нем он подробно объясняет, как TDD помогает решать проблемы программирования и лучше проектировать архитектуру.

Перейти на страницу:

Похожие книги

100 абсолютных законов успеха в бизнесе
100 абсолютных законов успеха в бизнесе

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

Брайан Трейси

Деловая литература / Маркетинг, PR, реклама / О бизнесе популярно / Финансы и бизнес