Если мы будем выполнять разработку, используя только внутренние программистские тесты (их называют тестами модулей – unit tests, – хотя они не вполне соответствуют этому определению), мы рискуем столкнуться с проблемой: полученная в результате этого система может оказаться не совсем тем или, что хуже, совсем не тем, что хочет получить пользователь. Программист будет работать над программой, которая, по его мнению, должна быть полезна, однако у пользователя может оказаться совершенно другое мнение. Чтобы решить проблему, можно разработать набор тестов на уровне приложения. Разработкой этих тестов должны заниматься сами пользователи (при поддержке программистов). Написанные пользователями тесты должны точно определять, что именно должна делать разрабатываемая система. Такой стиль можно назвать разработкой через тестирование на уровне приложения (ATDD, Application Test-Driven Development).
Встает техническая проблема: как написать и запустить тест для функциональности, которая еще не существует? Мне кажется, что всегда можно найти способ решения этой проблемы. Например, можно разработать интерпретатор, который будет вежливо сигнализировать о том, что обнаружен тест, выполнить который на данный момент невозможно по причине отсутствия в системе необходимых возможностей.
Существует также социальная проблема. У пользователей (на самом деле я имею в виду команду, в состав которой входят пользователи) появляется новая обязанность: разработка тестов. Процедура разработки тестов уровня приложения требует добавления дополнительного этапа в цикл работы над продуктом, – а именно, разработка пользовательских тестов выполняется перед началом реализации очередного объема функциональности. Организации часто сопротивляются подобному сдвигу ответственности. Новый этап требует координированных усилий множества членов команды, то есть перед тем, как приступить непосредственно к разработке кода, члены команды вынуждены потратить время на разработку пользовательских тестов.
Описанная в данной книге методика TDD целиком и полностью находится под вашим контролем. Иначе говоря, выполнение TDD зависит только от одного человека – от вас. Если у вас возникло желание, вы можете начать использовать ее с сегодняшнего дня. Однако если вы будете смешивать ритм красный – зеленый – рефакторинг с техническими, социальными и организационными проблемами разработки пользовательских тестов, вы вряд ли сможете добиться успеха. В данном случае следует воспользоваться правилом «Тест одного шага» (One Step Test). Сначала добейтесь равномерности ритма красный – зеленый – рефакторинг в собственной практике, затем расширьте область применения TDD.
Еще один аспект ATDD: определение длины цикла между разработкой теста и получением результатов его работы. Если заказчик написал тест, а потом в течение десяти дней ждет его срабатывания, это значит, что он большую часть времени смотрит на красную полосу. Если я работаю в стиле TDD на уровне программиста, я
• немедленно получаю зеленую полосу;
• упрощаю внутренний дизайн.
Как перейти к использованию TDD в середине работы над проектом?У вас есть некоторый объем кода, про который можно сказать, что он корректно работает в большей или меньшей степени. Теперь вы хотите разрабатывать весь новый код в рамках концепции TDD. Что делать?
О проблеме перехода на использование TDD в середине работы над проектом можно написать целую книгу (или даже несколько книг). В данном небольшом разделе я очень поверхностно затрону несколько связанных с этим вопросов.
Самая большая проблема заключается в том, что код, изначально написанный без тестов, как правило, сложен в тестировании. Интерфейсы и взаимосвязи между объектами недостаточно хорошо спроектированы, поэтому сложно изолировать некоторый кусок логики, запустить его и проверить результаты.
«Надо это исправить», – скажете вы. Да, однако любой рефакторинг (без применения средств автоматизации), скорее всего, приведет к возникновению ошибок, и эти ошибки сложно будет обнаружить, так как у вас нет тестов. Проблема яйца и курицы. Змея кусает себя за хвост. Замкнутый цикл саморазрушения. Что же делать?
Прежде всего скажу, чего делать не надо: не надо писать тесты для всего кода и выполнять рефакторинг всего кода. Для этого может потребоваться несколько месяцев, в течение которых у вас не будет времени добавить в систему новой функциональности. Если вы тратите имеющиеся у вас деньги и при этом не зарабатываете новых, долго вы не протянете.
Поэтому прежде всего мы должны ограничить область планируемых нами изменений. Если мы видим часть системы, которую можно существенно улучшить, но которая вполне может быть оставлена без изменений на текущий момент, мы оставляем их без изменений. Возможно, взглянув на код и вспомнив грехи прошлого, вы не сможете удержаться от слез, однако возьмите себя в руки, – если код не требует немедленного вмешательства, лучше не изменять его.
Во-вторых, мы должны разорвать замкнутый круг между тестами и рефакторингом. Мы можем использовать в качестве обратной связи не только тесты, но и другие способы, например чрезвычайно осторожная работа в паре с партнером. Мы можем использовать обратную связь более высокого уровня, например тесты на уровне всей системы. Мы знаем, что такие тесты не являются адекватными, однако они прибавляют нам уверенности. Благодаря такой обратной связи мы можем сделать части кода, нуждающиеся в изменении, более удобными для внесения изменений.
Через некоторое время части системы, которые постоянно меняются, станут выглядеть так, как будто их разработали с использованием TDD. Мы медленно углубимся в дремучий лес наших старых ошибок.
Для кого предназначена методика TDD?Каждая практика программирования явно или не явно базируется на системе ценностей. TDD не исключение. Если вам нравится лепить вместе куски кода, которые более-менее работают, и вы счастливы думать, что вам не придется возвращаться к полученному в результате этого коду в дальнейшем, значит, TDD – не для вас. Методика TDD базируется на очаровательно-наивном предположении программиста о том, что чем красивее код, тем вероятнее успех. TDD помогает вам обращать внимание на правильные вопросы в подходящие для этого моменты времени.
