TDD — разработка через тестирование

TDD, test-driven development или процесс разработки через тестирование — это методология разработки программного обеспечения, которая основывается на повторении коротких циклов разработки — Red, Green, Refactor:

1. Пишется тест или набор тестов, покрывающих желаемое изменение в системе. Написание тестов позволяет лучше понять цель разработки. На этом шаге написанные тесты не должны проходить. «Проваленные» тесты в интерфейсе сред разработки выделяются красным цветом, поэтому эту фазу называют Red.
2. Пишется программный код, который реализует требуемое поведение системы и позволяет пройти написанный тест. На этом шаге основная цель — это только добиться прохождения тестов, оптимальная реализация не требуется. Успешные тесты в интерфейсах IDE окрашиваются в зелёный цвет, поэтому и фазу называют Green.
3. Проводится рефакторинг написанного кода с постоянной проверкой прохождения всех тестов. Задача фазы Refactor — это улучшение реализации под контролем автоматического тестирования — оптимизация производительности, улучшение читабельности кода и т.д.

При следовании этой методологии тесты пишутся всегда до написания кода, реализующего бизнес‑логику приложения. Или до исправления бага, если написание кода инициировано необходимостью исправить выявленную ошибку.

Тестирование программного обеспечения

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

Процедура тестирования может осуществляться вручную, но может быть и автоматизирована. В случае автоматического тестирования проверка работоспособности и правильности работы приложения осуществляется гораздо быстрее, полноценнее и фактически чаще (в сравнении с ручным тестированием).

Цикл разработки по TDD

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

TDD по шагам:

• Добавить тест для новой и еще не реализованной функциональности или для воспроизведения существующего бага.
• Запустить все тесты и убедиться, что новый тест не проходит.
• Написать код, который обеспечит прохождение теста.
• Запустить тесты и убедиться, что они все прошли успешно: прохождение нового теста подтверждает реализацию новой функциональности или исправление существующей ошибки, а прохождение остальных позволяет удостовериться, что ранее реализованная функциональность работает по‑прежнему корректно.
• Заняться рефакторингом и оптимизацией — улучшение сопровождаемости и быстродействия целесообразно осуществлять уже после того, как получилось добиться проверяемой работоспособности. Вносить изменения в код под контролем прохождения тестов всегда проще и надёжнее.
• Перезапустить тесты и убедиться, что они все ещё проходят успешно.
• Повторить цикл.

Преимущества TDD

Эта методология позволяет добиться создания пригодного для автоматического тестирования приложения и очень хорошего покрытия кода тестами. ТЗ переводится на язык автоматических тестов, то есть всё, что программа должна делать, проверяется. Если в приложении выявляются баги, то выявленная ошибка сначала покрывается тестами, а затем уже исправляется, что исключает регресс с повторным появлением ранее исправленных ошибок.

Также TDD часто упрощает программную реализацию: исключается избыточность — если компонент проходит тест, то он считается готовым. Если же существующие тесты проходят, но работает компонент не так, как ожидается, то это значит, что тесты пока не отражают всех требований, а это повод добавить новые тесты.

Архитектура программных продуктов, разрабатываемых таким образом, обычно лучше (в приложениях, которые пригодны для автоматического тестирования, обычно лучше распределяется ответственность между компонентами, а выполняемые сложные процедуры декомпозированы на более простые). Стабильность работы приложения, разработанного через тестирование, также выше за счёт того, что все основные функциональные возможноси программы покрыты тестами и их работоспособность регулярно проверяется.

Сопровождаемость проектов, где тестируется всё или практически всё, очень высока — разработчики могут не бояться вносить изменения в код, если что‑то пойдёт не так, то об этом ещё до релиза сообщат результаты автоматического тестирования.

Если резюмировать, то TDD имеет следующие «плюсы»:

• Повышение качества кода — тесты становятся «живой документацией», описывающей требуемое поведение системы, а код изначально проектируется для тестируемости, что снижает связанность компонентов.
• Раннее обнаружение ошибок — тесты выявляют баги на этапе разработки или тестирования, а не в продуктивной среде.
• Упрощение рефакторинга — вносить изменения в работающий проект не страшно, если есть уверенность, что тесты «поймают» неожиданные побочные эффекты и баги.
• Фокус на требованиях — написание тестов заставляет разработчика изначально определить, что должна делать система, прежде чем решать, как это реализовать.

Рациональное применение TDD

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

Стоит помнить, что TDD — это одна из наиболее требовательных к покрытию тестами методологий, и что не стоит сравнивать только две крайности — TDD и разработку вообще без тестирования.

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

Не стоит использовать TDD при разработке прототипов, при проверке бизнес‑гипотез или в исследовательских задачах с неясными требованиями — многократное переписывание не только бизнес‑логики, но и всех тестов, весьма ресурсоёмкая задача. Тоже самое касается и очень маленьких или «одноразовых» проектов, где окупаемость потраченных на тесты усилий будет незначительна.

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

Заключение

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