Что хотят услышать интервьюеры:

Да, моки обычно используют, когда нужно изолировать тестируемый код от внешних зависимостей. Это помогает проверить именно логику системы, а не поведение базы данных, API или очередей. Важно уметь объяснить, где моки полезны, а где лучше использовать реальные интеграционные тесты.

Определение:

Мок — это подменный объект, который имитирует поведение зависимости в тесте. Его используют, чтобы контролировать входные данные, избегать внешних вызовов и проверять взаимодействие с зависимостью. Обычно моки помогают тестировать код быстрее, стабильнее и предсказуемее.

Пример использования:

Допустим, есть сервис оформления заказа, который отправляет уведомление через внешний email-сервис. В юнит-тесте реальную отправку письма делать не нужно — вместо этого подставляют мок email-сервиса и проверяют, что метод отправки вызван с нужными параметрами.

from unittest.mock import Mock

class OrderService:
    def __init__(self, email_client):
        self.email_client = email_client

    def create_order(self, user_email):
        # логика создания заказа
        self.email_client.send_confirmation(user_email)
        return True

def test_create_order_sends_email():
    email_client = Mock()
    service = OrderService(email_client)

    result = service.create_order("user@example.com")

    assert result is True
    email_client.send_confirmation.assert_called_once_with("user@example.com")

Пояснение кода:

Mock() создаёт подмену для внешней зависимости email_client.
OrderService получает эту зависимость через конструктор, что позволяет легко подменять её в тесте.
Вызов create_order() выполняет бизнес-логику и обращается к мок-объекту вместо настоящего email-сервиса.
Проверка assert_called_once_with(...) подтверждает, что сервис вызвал нужный метод с правильным аргументом.
Реальная отправка письма не происходит, поэтому тест не зависит от сети и внешней системы.

Ключевые моменты:

Моки нужны для изоляции юнит-тестов от внешних систем.
Их удобно использовать для проверки факта вызова метода и переданных аргументов.
Не стоит мокать всё подряд: слишком много моков делает тесты хрупкими и плохо отражающими реальное поведение.
Для проверки интеграции между компонентами лучше подходят интеграционные тесты с реальными зависимостями или тестовыми окружениями.
Хорошая практика — мокать внешние сервисы, время, сеть, очередь сообщений и другие нестабильные зависимости.

Используете ли вы моки при написании тестов?