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

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

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

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

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

Например, есть сервис оформления заказа, который отправляет письмо через почтовый клиент. В тесте почтовый клиент заменяют мок-объектом, чтобы проверить, что письмо действительно вызывается с нужными параметрами, но без реальной отправки.

from unittest.mock import Mock

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

    def place_order(self, email):
        self.mailer.send(email, "Your order is confirmed")
        return True

def test_place_order():
    mailer_mock = Mock()
    service = OrderService(mailer_mock)

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

    assert result is True
    mailer_mock.send.assert_called_once_with("user@example.com", "Your order is confirmed")

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

В примере mailer_mock — это мок вместо реального почтового клиента.
OrderService получает зависимость через конструктор, поэтому в тесте её легко подменить.
После вызова place_order() проверяется не результат отправки письма, а факт вызова метода send() с нужными аргументами.
Такой подход позволяет тестировать бизнес-логику без внешних побочных эффектов.

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

Моки нужны для изоляции тестов от внешних зависимостей.
Они позволяют проверять вызовы, аргументы и количество обращений к зависимости.
Мокать стоит внешние сервисы, сеть, БД, файловую систему, а не собственную бизнес-логику.
Злоупотребление моками делает тесты хрупкими и слишком привязанными к реализации.
Полезно уметь различать mock, stub и fake, хотя на практике термины иногда смешиваются.

Имеете ли вы опыт создания мок-объектов для тестирования?