Когда моки вредят
Вопрос
Можно ли переборщить с моками? Как понять, что тесты стали хрупкими?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Тесты повторяют реализацию: проверяют вызовы вместо результата
Любой рефакторинг ломает тесты без изменения поведения
Мокать стоит границы системы и неуправляемые зависимости, а не всё подряд
Мок DbContext или IQueryable почти всегда плохая идея
Классическая и лондонская школы модульного тестирования
Проверять наблюдаемое поведение: состояние и ответы
Что могут спросить следом
- Что такое управляемые и неуправляемые зависимости?
- Как тестировать код, который работает с IQueryable?
Разбор
Да, и это частая проблема. Если тест мокает все зависимости и проверяет через Verify, что метод A вызвал B с такими-то аргументами, он фактически дублирует реализацию. Любой рефакторинг без изменения поведения ломает тесты, и команда начинает их ненавидеть. Это признак хрупкости.
Я придерживаюсь подхода, где мокаются только неуправляемые зависимости: то, что видно снаружи системы, например отправка письма, платёжный шлюз, очередь. Там проверка взаимодействия и есть проверка поведения. А управляемые зависимости, своя база и свои классы, использую настоящие и проверяю результат: состояние или ответ API.
Отдельный антипаттерн: мокать DbContext или IQueryable. Мок не воспроизводит перевод LINQ в SQL, и тест проходит там, где реальный запрос упадёт. Такую логику проверяю интеграционным тестом на настоящей базе.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.