Почему я перестала писать тесты после кода и начала с них — и как это изменило мою жизнь

Привет, ребята! 👋 Я тут недавно пересматривала свой подход к тестированию и поняла, что годами делала одну и ту же ошибку — сначала код, потом тесты. Казалось бы, логично: написал фичу, проверил, что она работает, и пошёл дальше. Но на практике это приводило к тому, что баги находились на продакшене, а регрессионные тесты становились костылями. Я решила попробовать TDD (Test-Driven Development) по-настоящему, не просто как модную концепцию, а как ежедневную практику. И знаете что? Это сломало мой мозг, но в хорошем смысле. Во-первых, TDD заставил меня думать о поведении кода до того, как я написала хоть одну строчку реализации. Вместо того чтобы гадать, как будет работать метод, я сначала описала, что он должен возвращать на разных входных данных. Например, я тестировала API для загрузки файлов: написала тест, который проверяет, что при передаче пустого файла возвращается 400 с сообщением «Файл пуст». Когда я потом писала код, я уже знала, куда двигаться, и не тратила время на лишние if-ы. Баги стали редкостью, а код — чище. Во-вторых, это изменило мою работу с legacy-кодом. Раньше я боялась трогать старые модули, потому что не понимала, как они себя поведут. Теперь я сначала набрасываю тесты на существующее поведение (characterization tests), а потом рефакторю. Пример: в проекте была функция, которая обрабатывала логи и падала на пустых строках. Я написала тест, который воспроизводил этот сценарий, потом зафиксировала ожидаемый результат (ошибка), а затем переписала код, чтобы он обрабатывал пустые строки корректно. Тест упал, я исправила реализацию — и всё зелёное. Без TDD я бы, скорее всего, случайно сломала логику. Но есть и подводные камни. Сначала мне казалось, что TDD замедляет разработку — тесты пишутся дольше, чем сам код. Но потом я заметила, что время на отладку сократилось в разы. Раньше я тратила часы на поиск бага, который мог бы быть обнаружен на этапе проектирования. Теперь же я запускаю тесты и вижу красную точку — и сразу знаю, что не так. Это как навигатор: он не говорит, как ехать, но предупреждает, где яма. Ещё один важный момент — тесты стали документацией. Когда я возвращаюсь к своему коду через месяц, я смотрю не на комментарии (их нет), а на тесты. Они рассказывают, как должна работать каждая функция. Например, тест на пароль: assert validate_password('short') == False, assert validate_password('LongEn0ugh!') == True — и сразу ясно, что длина и символы имеют значение. Никаких лишних слов. Кстати, коллеги сначала скептически отнеслись — мол, это для новичков. Но я показала им статистику: после внедрения TDD в нашем микросервисе количество багов на проде упало на 30% за месяц. Теперь они тоже пробуют. А вы пробовали TDD? Или у вас есть свои лайфхаки, как не писать тесты после того, как код уже улетел в релиз? Делитесь опытом, мне интересно, кто как выкручивается! 😄