Бэкендошная
110 subscribers
2 photos
66 links
Канал о backend-разработке и backend-разработчиках: языки программирования, алгоритмы и структуры данных, методологии, околопрограммистские темы и никакого (ну почти) фронтенда
Download Telegram
Пишу юнит-тесты почти 5 лет и основные сражения, которые я видел по их поводу, заключались только в том - писать по TDD или нет.

Но сегодня наткнулся на то, что оказывается есть два способа тестирования - классический из Детройта и мокистский из Лондона.

Основная разница только в том, какая часть является юнитом и какие зависимости нужно заменять заглушками с ожидаемым поведением. В классической школе - юнитом является поведение и заглушками заменяются только те зависимости, которые могут повлиять на другие тесты или являются внешними - БД, файловая система, http-запросы. А при лондонском подходе - почти все зависимости заменяются на заглушки и тестируется только отдельный класс и его методы. Это делает тесты по-настоящему изолированными.

Подробнее про различия в статье

Что касается меня и моего выбора относительно юнит-тестов, то для бизнесового кода я конечно же выберу подход Детройта - нет смысла делать моками абсолютно все зависимости, так как эта изоляция приносит больше вреда чем пользы, напрмиер при рефакторинге - когда поведение у вас не меняется, но при этом тесты падают если вы меняете внешний вызов или исправляете SQL-запрос например.

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

А что насчет вас? Какой подход выберите?

#coding #test