'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Главный эффект TDD лежит в стороне от тестов. Чтобы написать тест первым, приходится заранее решить, как модуль будет вызываться и что вернёт. Проектирование интерфейса случается до реализации, и это меняет форму кода сильнее, чем сами проверки.
Цикл
- Красный: тест написан и падает. Иногда он даже не компилируется, и это нормально.
- Зелёный: код доводят до прохождения теста самым коротким путём, допуская любые упрощения.
- Рефакторинг: убирают дублирование и наводят порядок, тесты при этом остаются зелёными.
Шаги короткие: Бек описывал их длиной в минуты.
Чего TDD не даёт
Покрытие тестами и TDD — разные вещи. Тесты, дописанные после кода, дают ту же цифру покрытия и никак не влияют на устройство модуля. Обратное тоже верно: команда с полным TDD пропустит ошибку, которой нет в тестах, потому что тест проверяет только то, что автор придумал проверить.
Где буксует
Тяжелее всего TDD идёт на коде, плотно сросшемся с внешним миром: интерфейсы, интеграции, унаследованные модули без швов. Обычно там начинают с тестов на уровне поведения, а внутрь спускаются по мере того, как код удаётся разъединить.
- Логика с ветвлениями и расчётами: скидки, тарифы, права доступа
- Код, который будут менять долго и часто
- Исправление ошибки: тест воспроизводит её до правки
- Прототип, который выбросят после проверки гипотезы
- Вёрстка и визуальные детали интерфейса
- Код, целиком состоящий из вызовов внешней системы
В биллинге появляется ошибка: скидка для годовой подписки считается от суммы, к которой уже применили скидку за объём. Разработчик начинает с теста, который повторяет случай клиента и падает. Затем правит расчёт до зелёного. Затем разносит два вида скидок по отдельным функциям, потому что тест уже страхует поведение. Тест остаётся в наборе и ловит ту же ошибку через полгода при переписывании тарифов.
Начинайте с ошибок. Правило «на каждый баг сначала тест» приживается легче, чем полный переход на цикл, и сразу даёт видимую пользу: одна и та же ошибка перестаёт возвращаться. В карточке задачи на исправление удобно держать ссылку на тест — при разборе повторного обращения сразу видно, что именно проверяется.