Все слышали про TDD? Тот, про который все так усердно спрашивают на собеседованиях; который обсуждается почти всеми разработчиками, но так же осознанно забывается, когда речь заходит о «DEVELOPER_NAME, возьми задачу в работу»?

Что ж, если вы так же слышали, все думали-хотели, но так и не заставили себя попробовать внедрить данный подход в рабочий процесс, то к вашим услугам данный пост, дабы или рассказать вам что-то новое, или напомнить о старом, чтобы вы могли еще раз поторговаться с собой на тему «надо ли нам это в работе»

TDD - это Test-Driven Development. Это подход к разработке; это образ мышления, это стиль разработчика, а главное - это очень сложно инжектить в рабочий процесс, если ты не совсем понимаешь философию тестов.

На самом деле эта философия очень проста: в идеальных фирмах идеальные разработчики покрывают свой код тестами, дабы реализовывалось так нами любимое fail-fast. Опустим момент, что тесты никто писать не любит, и средний coverage всех проектов дай бог превышает 10-20%.

TDD же прямо в глаза заявляет: если мы и так будем писать тесты, то почему бы не писать их в первую очередь? Ведь, согласитесь, когда мы получаем в работу задачу, то проделываем одинаковые шаги: ♨️ Смотрим на документацию фичи, которую нужно сделать; ♨️ Выделяем некую логику фичи, т.е. переводим задачу в алгоритмический вид (при отсутствии этих алгоритмов в документации); ♨️ Заводим некоторые entity и DTO; ♨️ Заводим репозитории, сервисы и контроллеры; ♨️ Полируем все это дело логами.

Как это сделать через TDD? Да так же, как и всегда, за небольшим исключением: не надо бежать и неистово крушить клавиши, выводя на экран вызовы репозиториев, экстрактируя методы, дабы был «чистый код» и добавляя всякие log.info(“Что-то не так»); Просто выделите ключевые моменты фичи и напишите на них тесты.

Допустим, у нас задача по созданию и обработке заказа с некоторой дополнительной логикой. Допустим, мы из документации выделили следующее: ♨️ В модели есть некоторый уникальный атрибут; ♨️ Для обработки заказа нужно сделать первичную валидацию; ♨️ Нужно, чтобы данные клиента имелись где-то там (бд, другой сервис и тд).

Следуя TDD мы не пойдём писать бизнес-логику, нет! Мы сразу нырнем в тесты, и оформим методы для этих ключевых вещей: ♨️ Тест, ожидающий ошибку при дублировании уникального атрибута; ♨️ Тест на всеми любимый 404; ♨️ Тест на валидность входных данных; ♨️ Тест для проверки дополнительных вещей.

Написали? Теперь можно спокойно идти писать основную логику и добавлять по необходимости еще тесты, имея в рукаве следующее: ♨️ У вас уже есть покрытие тестами; ♨️ При реализации бизнес-логики вы точно не пропустите важных вещей из документации; ♨️ С большой вероятностью вы получите ачивку «самый быстрый аппрув PR»; ♨️ Вы с большой вероятностью найдёте то, что аналитик мог упустить в документации; ♨️ Партия быть вами доволен, партия дать вам миска рис.

Конечно, у этого подхода есть и минусы. Если вы только начинающий разработчик, не умеете «дебажить в голове» или документация у вас не первой свежести и качества, то время на разработку в такой философии может увеличиться в разы. Однако, чем больше уровень ваших хардов, чем чаще вы будете пользоваться TDD - тем легче и качественнее пойдет ваша разработка.

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

Поэтому, давайте еще раз подумаем о TDD, дружно покиваем головой и сойдемся на том, что «TDD это здорово и нужно, поэтому я как-нибудь в другой раз обязательно попробую эту штуку на практике, а пока пойду на созвон, там опять что-то не работает🍺»

Пишите свои мысли, согласия и несогласия, а так же не забывайте, что это открытое сообщество, в котором любой желающий может создавать посты и делиться своими мыслями, знаниями и болью♨️