Есть небольшая книжка, написанная более 20 лет назад, переведенная на русский как «Экстремальное программирование». При обсуждении этой книжки с коллегами я часто встречал мнение, что она только про то, что надо сначала тесты писать, а потом код и больше в ней нет ничего полезного. Когда у самого добрались руки до нее, я понял, что видимо читают выжимки из статей на Хабре или просто статьи википедии, потому что там есть и паттерны проектирования, и правила написания тестов и практические примеры. А все запоминают только мантру «Утром тесты — вечером стулья код».
В ней есть вот такой цикл (см. картинку), который описывает 90% времени работы с кодом (еще 10% мы думаем что делать и как, но это не обязательно). Автор книги считает важным, что все должно начинаться с тестов, и поэтому стрелочка сверху заходит туда, потом мы получаем красные тесты, исправляем код, рефакторим его и так по новой. Так и получается TDD (Test Driven Development).
Главный секрет TDD не в том, что тесты пишутся первыми, а в том, что цикл обратной связи должен занимать не больше 15 минут.
Чтобы программист мог проходить его за рабочий день много раз, чтобы можно было корректировать свою работу по завершению каждой итерации, чтобы каждый следующий шаг для решения рабочей задачи требовал минимум контекста и времени.
За контекст отвечает уровень декомпозиции задачи. А за время — структура исходного кода, организация тестов. Поэтому в книжке описываются рекомендации для поддержания проекта в таком состоянии. Очень советую всем прочитать.
По собственному опыту всегда гораздо легче работать с приложением, у которого может быть не идеально соблюден SOLID, YAGNI, DRY и вот это все, но есть хорошее покрытие тестами и эти тесты можно без танцев с бубном запустить в любой момент и получить обратную связь: «Работает код или нет?».
Один из моих тимлидов (привет, Саша) приучил меня к правилу, которое я соблюдаю до сих пор:
Организовывать код в проектах надо так, чтобы любой разработчик, даже только что пришедший в команду, мог за 2 команды в консоли установить зависимости для работы и локально запустить тесты. Тесты запущенные локально должны соответствовать тестам в пайплайне.
Да, это требует дополнительной подготовки шаблона репозитория и некоторых усилий на поддержание этого в CI/CD, и также это требует мета‑знаний по организации кода в нескольких репозиториях, выделения общего кода в библиотеки и т д, но выхлоп от экономии времени в ежедневной работе стократный. Когда ты в любой момент времени точно знаешь, что у тебя работает, а что нет, и можешь без страха что‑то сломать вносить изменения. Добавьте к этому линтеры и форматтеры в пайплайне, pre‑commit, чтобы ничего лишнего не попадало в общий репозиторий без проверок и вы снимаете с себя и коллег 80% рутины на ревью PR‑ов и ручном тестировании.
Это также хороший маркер уровня разработки в команде (компании). Если вы видите такие проблемы в своем проекте и никак их не решаете на протяжении времени, то стоит задуматься. Обычно процессы в команде не относятся к зоне ответственности обычного разработчика, но попробуйте предложить изменения. Эти улучшения процессов относятся к тем вещам, которые бизнес сочтет важными, т. к. разработчики начнут меньше времени тратить на рутину и заниматься полезными вещами. Главное правильно сделать акцент на уменьшении стоимости фич после внедрения.
Если вы до сих пор думаете, что TDD — это про «писать тесты первыми», перечитайте Кента Бека. На самом деле это про скорость. А скорость — это деньги.
