Что не так с юнит-тестами


Помните мой недавний пост про изменении концепции тестирования на trophy? Там мы видим что количество юнит-тестов сведено к минимуму, что идет в разрез с общепринятым “пишем в первую очередь юниты”. И в этом посте я хочу рассказать про проблемы юнитов, которые существовали всегда и многие опытные разработчики на это не раз натыкались.

Часто говорят, что юниты помогают рефакторить код. Я же скажу, что именно юниты мешают его рефакторить. Полезный рефакторинг, как правило это не изменение того как написан, например, конкретный цикл, это переработка абстракций, выделение слоев, перемещение кода, перераспределение кода между функциями и методами. Что происходит с юнитами в таком случае? Правильно, они становятся полностью бесполезными, так как их придется переписывать. В моей практике была ситуация, когда 35 000 строк кода юнит тестов просто выкинули, так как в проекте делался важный рефакторинг и команда поняла что просто не потянет апгрейд тестов (по факту написание их с нуля).

Но и это еще не все, наличие большого числа таких юнитов заранее пугает разработчиков, так как они понимают что рефакторинг заставит их все переписывать, что убивает любую мотивацию рефакторить код.

Следующий пункт про гарантии. Все знают что гарантии от юнитов минимальны, поэтому их наличие не может быть оправданием того, что не пишутся тесты более высокого уровня, например, интеграционные. И пишутся они тоже программистами. Тогда возникает вопрос, зачем писать юниты, если уже есть интеграционные?

Ответом может быть: но они же быстрые. В реальности, в современных фреймворках скорость выполнения интеграционных тестов достаточно быстрая, чтобы не испытывать проблем. Да, при этом есть определенные техники работы с базой данных (не Моки!) которые надо соблюдать, но это уже давно отработанная история. Медленно же выполняются e2e тесты, но они пишутся независимо от юнит тестов, поэтому тут даже нет выбора.

p.s. Какие тесты в основном пишут в вашем проекте?