Работал ли ты с моками в тестировании

Что проверяют

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

Как отвечать

Начните с того, что подменяете и зачем: сеть, база, время, случайность, файловая система, сторонние SDK. Остальное лучше оставить настоящим.

Инструменты: unittest.mock с patch, Mock, MagicMock, в pytest ещё monkeypatch и плагин pytest-mock. Для HTTP удобнее подмена на уровне транспорта (responses, respx): она проверяет и то, какой запрос ушёл.

Ключевое правило: патчить надо там, где имя используется, а не там, где объявлено.

# app/service.py:  from app.client import fetch
with patch("app.service.fetch") as m:   # так работает
    ...
with patch("app.client.fetch") as m:    # так тест ничего не подменит
    ...

Дальше скажите про autospec=True и create_autospec: они сверяют сигнатуру с настоящим объектом, поэтому переименованный аргумент ломает тест, а не проходит мимо. И про проверку вызова через assert_called_once_with и call_args: смысл мока часто именно в том, что наружу ушёл правильный запрос.

Хорошо звучит различение: стаб отдаёт готовый ответ, мок ещё и проверяет взаимодействие, фейк это лёгкая рабочая реализация вроде базы в памяти.

Где спотыкаются

Мокают всё подряд, включая соседние функции своего же модуля. Тест становится зеркалом реализации: любой рефакторинг красит его в красный, а настоящую регрессию он не ловит.

Обычный Mock отдаёт мок на любой атрибут. Метод в рабочем коде переименовали, тест продолжает дёргать старое имя и остаётся зелёным. Лечится это spec или автоспеком.

Забывают убрать подмену. Патч, поставленный вручную без контекстного менеджера или декоратора, течёт в соседние тесты, и порядок запуска начинает влиять на результат.