Comments 6
Спасибо! Мне, как человеку, которому предстоит начать писать тексты впервые в жизни, было полезно.)
Почему хорошие разработчики пишут плохие юнит-тесты
Потому автор использует такое выдуманное им определение "хорошести", в которое не входят юнит-тесты.
Смиритесь с избыточностью, если она поддерживает простоту.
О да... Этот метод очень хорошо работает если для разработки продукта использовать правило: write-once-modify-never. Иначе на этой избыточности можно хорошо прогореть, особенно если писать тесты для чтения. а не для тестирования. Недавно в подобном проекте делал исправление: добавил одно малюсенькое правило, которое зависит от дополнительного параметра в окружении. Всё бы хорошо было на бумаге: Посмотрел что с выключенным свойством все тесты не упали, написал пару тестов при включенном окружении - проверил правило. Но, прошлый программист с кюа пытались написать тесты именно выше написанным способом, а в окружении явно требовало указывать эти параметры. Из за чего мне пришлось вносить дефолтное поведение в более чем 3к тестов и писать ещё несколько тестов на новое правило. Забавное скажу вам занятие....
на любую здравую идею можно найти исключение.
это не делает идею менее здравой.
В том то и проблема в том что такие вещи очень хороши при нулевом зацеплении объектов в вакууме. В реальной сфере зацепление у объектов/функций почти никогда не нулевое. И даже не единичные. Даже если мы всегда обмазываемся DI, CI и прочими паттернами. И обычно они зацеплены на целый ряд сервисов и интерфейсов (и повезет если того же самого модуля). И изменение любого этого сервиса и интерфейса приводит к лавиообразной сложности поддержки тестового покрытия написанного методом copy-paste.
Тесты это тоже код, есть все инструменты которые позволяют писать тесты и компактно и используя "лучшие" практики.
Почему хорошие разработчики пишут плохие юнит-тесты