Продолжаем про юнит-тесты (я понял, что “юнит-тест” у меня с языка слетает автоматом, тогда как “модульные” - это что-то “академическое на старославянском”).
Начнем с того, что многие в принципе не считают такие тесты классическими тестами. Оно и правда, если юнит-тесты написаны по канонам*: “проверяется лишь одна функция одного юнита”, “все строго изолированно” и тп, то это лишь скорее просто инструмент разработчика.
Что он дает?
1. возможность запускать части кода без запуска всей системы, что обеспечивает:
• быструю обратную связь от вносимых изменений
• уверенность в вносимых изменениях
2. документация к коду
3. помощь в проектировании

Разберем коротенько по пунктам (заметки Капитана Очевидность, но я как-то не хочу их проскакивать)
1. Быстрый запуск кода - тут речь как про возможность “засунуть датчик” непосредственно в кишочки кода, так и про скорость выполнения самой проверки.
Когда у тебя есть возможность здесь и сейчас, без дополнительного окружения и ресурсов проверить, как выполняет свои задачи свеженаписанный код - это то, что нужно. К примеру, если функция по бинарному блобу определяет тип данных в нем, то не нужно проверять эту функцию запуская и дергая API сервиса, который где-то внутри себя использует эту функцию. Банальность и очевидность, но сплошь и рядом наблюдается (о причинах не сегодня). А если функция вызывается внутри десктоп приложения? Там с проверкой функции ”через приложение” вообще будет веселый аттракцион.
2. Документация. Есть интересная особенность памяти среднестатистического разработчика - она обнуляется по отношению к коду буквально через месяц (+/-). Некоторые только по истории гита определяют, что какое-то конкретное изменение кода было сделано именно ими. А уж про то, что именно код делает и для чего, так и подавно не помнят. Так вот тесты расположенные близко к коду (чаще всего те самые юнит-тесты), как раз помогают быстрее восстановить понимание предназначения кода и логики его работы. И да, конечно, это можно сделать и просто читая код. Но читая юнит-тесты, тем более хорошо написанные тесты с правильными названиями, сделать это намного быстрее. Тем более, что обычную документацию то редко кто пишет, а еще реже обновляет.
3. Проектирование. Использование юнит-тестов способствует (но не гарантирует) тому, что проверяемый ими код будет написан удобно, понятно, расширяемо. Потому что способность кода быть удобно тестируемым (тестируемость) напрямую связана с такими характеристиками качества кода, как изменяемость и поддерживаемость.
В этом месте можно было бы ввернуть про TDD (и я ввернул), но забавно, что сейчас это буквосочетание куда-то исчезло (только из моей инфоленты?). А то ли дело ра-а-аньше, трава зеленее, "TDD помогает" vs "TDD есть опиум для народа" и такие батлы в комментариях (тут тоже есть, если вы любитель попкорна).

Короче, юнит-тесты - это лишь инструмент разработчика: написал код так, чтобы потом его протестировать, проверил локально, остались какие-то артефакты имитирующие документацию. Работает в моменте здесь и сейчас.
Если юнит-тесты написаны канонично*, то с вероятностью 99% их надо выкинуть (=сильно переписать) при изменении того кода, который они проверяют. И именно от последнего всех и бомбит.

*по канонам завтра, потому что я не верю, что в телеге кто-то такие простыни читает. А вообще я так разошелся, что может и пятница будет без мемов, но это неточно.
#unit_testing #test_automation