Есть небольшая книжка, написанная более 20 лет назад, переведенная на русский как «Экстремальное программирование». При обсуждении этой книжки с коллегами я часто встречал мнение, что она только про то, что надо сначала тесты писать, а потом код и больше в ней нет ничего полезного. Когда у самого добрались руки до нее, я понял, что видимо читают выжимки из статей на Хабре или просто статьи википедии, потому что там есть и паттерны проектирования, и правила написания тестов и практические примеры. А все запоминают только мантру «Утром тесты — вечером стулья код».
В ней есть вот такой цикл (см. картинку), который описывает 90% времени работы с кодом (еще 10% мы думаем что делать и как, но это не обязательно). Автор книги считает важным, что все должно начинаться с тестов, и поэтому стрелочка сверху заходит туда, потом мы получаем красные тесты, исправляем код, рефакторим его и так по новой. Так и получается TDD (Test Driven Development).
Главный секрет TDD не в том, что тесты пишутся первыми, а в том, что цикл обратной связи должен занимать не больше 15 минут.
Чтобы программист мог проходить его за рабочий день много раз, чтобы можно было корректировать свою работу по завершению каждой итерации, чтобы каждый следующий шаг для решения рабочей задачи требовал минимум контекста и времени.
За контекст отвечает уровень декомпозиции задачи. А за время — структура исходного кода, организация тестов. Поэтому в книжке описываются рекомендации для поддержания проекта в таком состоянии. Очень советую всем прочитать.
По собственному опыту всегда гораздо легче работать с приложением, у которого может быть не идеально соблюден SOLID, YAGNI, DRY и вот это все, но есть хорошее покрытие тестами и эти тесты можно без танцев с бубном запустить в любой момент и получить обратную связь: «Работает код или нет?».
Один из моих тимлидов (привет, Саша) приучил меня к правилу, которое я соблюдаю до сих пор:
Организовывать код в проектах надо так, чтобы любой разработчик, даже только что пришедший в команду, мог за 2 команды в консоли установить зависимости для работы и локально запустить тесты. Тесты запущенные локально должны соответствовать тестам в пайплайне.
Да, это требует дополнительной подготовки шаблона репозитория и некоторых усилий на поддержание этого в CI/CD, и также это требует мета‑знаний по организации кода в нескольких репозиториях, выделения общего кода в библиотеки и т д, но выхлоп от экономии времени в ежедневной работе стократный. Когда ты в любой момент времени точно знаешь, что у тебя работает, а что нет, и можешь без страха что‑то сломать вносить изменения. Добавьте к этому линтеры и форматтеры в пайплайне, pre‑commit, чтобы ничего лишнего не попадало в общий репозиторий без проверок и вы снимаете с себя и коллег 80% рутины на ревью PR‑ов и ручном тестировании.
Это также хороший маркер уровня разработки в команде (компании). Если вы видите такие проблемы в своем проекте и никак их не решаете на протяжении времени, то стоит задуматься. Обычно процессы в команде не относятся к зоне ответственности обычного разработчика, но попробуйте предложить изменения. Эти улучшения процессов относятся к тем вещам, которые бизнес сочтет важными, т. к. разработчики начнут меньше времени тратить на рутину и заниматься полезными вещами. Главное правильно сделать акцент на уменьшении стоимости фич после внедрения.
Если вы до сих пор думаете, что TDD — это про «писать тесты первыми», перечитайте Кента Бека. На самом деле это про скорость. А скорость — это деньги.
Комментарии (14)
alrn
30.08.2025 14:50Хорошая мысля. Я согласен с тобой TDD - это реальн про скорость и качество, а не просто про порядок написания теста и кода. За 15 минут и возможность легко запустить тесты это прям мечта, экономит много времени и нервов
chaetal
30.08.2025 14:50Отвратительная мысль — свести систему поддерживающих друг друга идей и практик к одному плохо оформленному пожеланию. …Ну, и дополнить это ещё одним пожеланием, вообще не имеющим отношения к обсуждаемой теме.
nin-jin
30.08.2025 14:50Странно, что вы не стащили у меня и вторую картинку из этой статьи с исправленным циклом TDD:
chaetal
30.08.2025 14:50Можно уточнить?
Вы прочитали книгу Бека "Экстремальное программирование. Разработка через тестирование", и всё, что из неё вынесли — вот этот "секрет"?
Главный секрет TDD не в том, что тесты пишутся первыми, а в том, что цикл обратной связи должен занимать не больше 15 минут.
Я правильно понял?
andy-takker Автор
30.08.2025 14:50Уточнить нельзя)
И поняли неправильно)
Стандартная история про методологию разработки обговорена со всех сторон по 100 раз, захотелось высказать что-то, что мне лично показалось не очевидным, т. к. не вижу 100500 статей об этом. Может быть именно к TDD притянуто за уши, но впервые с этой идей столкнулся именно там. И мне понравилось, как другие советы и правила методологии эту идею дополняют.
chaetal
30.08.2025 14:50И жаль, что уточнить нельзя, а то я бы это сделал…
…Подтвердив, что TDD —конечно же! — про обратную связь. Но не только про неё.Весь "agile" про обратную связь. Всем хочется как можно быстрее понять, правильные решение было принято или нет.
Но вот только жизнь устроена так, что одного желания обычно недостаточно — нужно ещё придумать, как это желание воплотить в жизнь. И TDD — про комплекс мер по достижению этого (и, на самом деле, не только этого — так как и сама проблема сложная, многокритериальная, да ещё и динамическая).
В итоге как-то так получается, что, с одной стороны, вы подчёркиваете важную деталь, но при этом упускаете целое. И в результате статья больше не помогает, а, скорее, мешает понять (целостный) смысл TDD.Но при этом есть гипотеза, что стоит лишь чуть-чуть сместить акцент — говорить не про "Главный секрет TDD", а про "одну из (возможно, неочевидных …почему-то) целей, которые (действительно!) позволяет (не просто хочет, а именно позволяет — как раз благодаря комплексности) достичь TDD (…правда не сразу)", — как ценность статьи возрастёт немедленно и очень сильно.
И то, что понял не правильно — хотя очень старался понять правильно, — возможно, подтверждает эту гипотезу?
(Изложил многословно и сложновато, конечно — требуется рефакторинг. Но сначала надо заставит тест позеленеть.)
gsaw
Спорное утверждение. Несоблюдение SOLID может привести к усложнению юнит тестов. Начинают писать юнит тесты, которые должны проникнуть в такие дебри, что бы добиться хотя бы относительного покрытия, что мама не горюй, если боец до ночи не вернется до дому. Или юнит тесты даются с таким трудом, что получаются интеграционные тесты. Потом поддержка тестов приводит к тому, что либо их удаляют, потому как не ясно, что в ём сломалось, либо боятся код трогать и пишут рядом новый метод и новый юнит тест.
SolidSnack
Только, как мне кажется, TDD маленько не про это, так же как и не мешает оно ООП
chaetal
Вам не кажется!
andy-takker Автор
Я не хочу сказать, что соблюдать хорошие практики не надо (я за них обеими руками), лишь только, что мне легче работать с проектами, у которых есть хорошее покрытие тестами и эти тесты можно быстро прогнать.
Просто в реальной корпоративной разработке я повидал очень много разного и хорошей архитектуры, и SOLID и скрипты на 1.5к строк и оверинженерной архитектуры, где у каждого класса был свой абстрактный родитель, который даже мог быть пустым, но на всякий случай его создавали. Не всегда работаешь в идеальных условиях ¯\_(ツ)_/¯.
Я согласен, что тесты тестам рознь и бывают такие случаи, что лучше бы их не было, потому что становятся или очень хрупкими, или так обмазанные моками, что уже непонятно выполняется ли там хоть что-то реальное. Поэтому я и оговорился про хорошее покрытие. Эмпирически с чем работал, если > 70%, то уже все не так плохо в проекте. Такой код можно более менее спокойно рефакторить или пилить новые фичи.
Про хорошие практики тестов по крайней мере на Python еще точно поговорим в будущем.
nin-jin
Юнит тесты являются антипаттерном. Как, впрочем, и SOLID.