Это конечно перебор, но этот пример я привел как вариант того, что юнит тесты всегда быстрые

Замокан логгер :О

log-driven development

мой первый комментарий был “это история про дурачков, которые не хотели учиться писать тесты”

Причем рукописным моком, который поддерживал не всю функциональность оригинального логгера...

Писать юнит тесты тоже надо уметь, что тут еще скажешь. Покрытие это де метрика, оно не должно становится самоцелью

А есть гайды по написанию юнит-тестов?

Возможно не очень в тему, но я сталкивался с тем, что документация по сервисам отличается от поведения сервиса.
Моки проходят на ура, а в реальности не работает.

Веселее бывает другое, когда в проде ещё и инфраструктура отличается и (вот прям реальный кейс) перед сервисом воткнут nginx, у коготого гвоздями прибит request timeout и вместо ответа по спеке мы получаем неспецифиципованную HTTP ошибку.

Разработчики тоже, конечно, дурики - не учли, что всегда и везде может прилететь что-то неожиданное и (дело было на java) падали по unhandled exception, но это скорее ответ на то, что интеграционные тесты must have и они должны покрывать неожиданные сценарии (типа отвала базы данных у микросервиса, к которому ты обращаешься).

Что ни говори, книга Роя Ошерова  - лучший из учебников по юнит тестам. И там есть целая глава про то, что внутренне состояние алгоритмов проще дебажить чем покрывать тестами. Но покрывать - надёжнее конечно

И ещё - для чистых функций можно писать 100% надёжные проперти тесты, а любой юнит тест с моками нельзя считать абсолютно надёжным по определению

Любой тест с моками тестирует "юнит" в изоляции. Тест без моков - интеграционный тест. Означает ли это что юнит-тест нельзя считать надежным? Нет. Означает ли это, что юнит тест не тестирует интеграцию с объектом который замокан? Да. Юнит тест проверяет лишь то, какие параметры были переданы сущности которая замокана, сколько раз была вызвана функция или метод этой сущности и какие результаты она вернула.

> без моков = интеграционный
чистые функции не согласны

ну и то, что юнит тест проверяет, сколько раз был вызван мок - дикая завязка на реализацию

Объясните пожалуйста, как эти вещи связаны?

почему тест функции без зависимостей (= тест без моков) - интеграционный, а не юнит?

Потому что юнит тестирование предполагает изоляцию юнита от всех зависиомстей.

а если нет зависимостей?)

у нас нет чистых функций

что жаль, кстати, но уж как есть

ну и я бы не сказал, что юнит тест предполагает *изоляцию* от зависимостей
контроль над ними = да, предполагает
отсюда и моки и стабы

Очевидно, если нет зависимостей, нечего мокать. Я понимаю к чему вы ведете, но я выше говорил в контексте когда зависимости присутствуют.