Теория: Мокинг

В тестировании очень популярен мокинг. Технически он похож на стабинг, и из-за этого их часто путают. Но все же они служат разным целям и используются в разных ситуациях. В этом уроке мы разберемся, что такое мокинг и зачем он нужен.

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

В некоторых ситуациях требуется кое-что другое. Иногда нам нужно не получить результат работы функции, а проверить, выполняет ли она нужное нам действие — например, шлет правильный HTTP-запрос с правильными параметрами.

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

HTTP

Начнем с такого фрагмента кода:

@pook.on
def test_get_private_fork_names():
    # Возвращается мок, за которым можно следить
    mock = pook.get(
        "https://api.github.com/orgs/hexlet/repos",
        reply=200,
        response_json=[{"fork": true, "name": "one"}, {"fork": false, "name": "two"}],
    )

    get_private_fork_names("hexlet")
    # Убеждаемся, что вызов был сделан
    assert mock.calls == 1

Отслеживание выполнения какого-то действия — это и есть мокинг. Мок проверяет, что какой-то код выполнился определенным образом. Это может быть вызов функции, HTTP-запрос и тому подобное.

У мока две задачи:

• Убедиться в том, что событие произошло — например, функция передала данные
• Отследить, каким конкретно образом оно произошло — функция передала конкретные данные

Что дает нам такая проверка? В этом случае не очень много. Да, мы убеждаемся, что вызов был, но само по себе это еще ни о чем не говорит. В чем же тогда польза моков?

Представьте, что мы бы разрабатывали библиотеку PyGithub — ту самую, что выполняет запросы к GitHub API. Вся суть этой библиотеки в том, чтобы выполнить правильные запросы с правильными параметрами. Поэтому там нужно обязательно проверять выполнение запросов с указанием точных URL-адресов. Только в таком случае можно быть уверенными, что она выполняет верные запросы.

В этом ключевое отличие мока от стаба:

• Стаб устраняет побочный эффект, чтобы не мешать проверке результата работы кода — например, возврату данных из функции
• Мок фокусируется на том, как конкретно работает код, что он делает внутри

При этом чисто технически мок и стаб создаются почти одинаково, за исключением того, что на мок вешают ожидания, проверяющие вызовы. Из-за этого моками часто называют стабы. Для себя всегда пытайтесь понять, о чем идет речь. Это важно, потому что от этого зависит фокус тестов.

Функции

Моки довольно часто используют с функциями (методами). К примеру, они могут проверять:

• Вызвана ли функция, сколько раз ее вызвали
• Какие аргументы переданы в функцию, сколько всего аргументов
• Что именно вернула функция

Предположим, что мы хотим протестировать функцию for_each(). Она вызывает колбек для каждого элемента коллекции:

def for_each(coll, func):
    for c in coll:
        func(c)


for_each([1, 2, 3], lambda v: print(v))
# => 1
# => 2
# => 3

Эта функция ничего не возвращает, поэтому напрямую ее не протестировать.

Можно попробовать сделать это с помощью моков. Проверим, что она вызывает переданный колбек и передает туда нужные значения. Сделаем это с помощью модуля mock, который входит в стандартную библиотеку Python как часть unittest:

from unittest.mock import Mock


def test_for_each():
    mock = Mock()

    for_each([1, 2, 3], lambda v: mock(v))

    # Проверяем, что она была вызвана с правильными аргументами нужное количество раз
    assert mock.call_count == 3
    mock.assert_any_call(1)
    mock.assert_any_call(2)
    mock.assert_any_call(3)

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

Можно сказать, что этот тест действительно проверяет работоспособность функции for_each(). Но можно сделать это проще, без мока и без завязки на внутреннее поведение. Для этого достаточно использовать замыкание:

def test_for_each():
    result = []
    numbers = [1, 2, 3]
    for_each(numbers, lambda x: result.append(x))
    assert result == numbers

Объекты

Кроме использования моков для тестирования функций, они также могут использоваться для тестирования объектов.

В тестировании объектов моки могут использоваться для имитации поведения объектов, от которых зависит тестируемый объект. Например, если объект A зависит от объекта B, то можно создать мок-объект для объекта B и использовать его в тестах объекта A. Это позволит тестировать объект A, не затрагивая объект B и его зависимости.

from unittest.mock import Mock


class MyObject:
    def __init__(self, dependency):
        self.dependency = dependency

    def my_method(self, arg):
        # какой-то метод, который зависит от зависимости
        return self.dependency.some_method(arg)


# Создаем мок-объект для зависимости
mock_dependency = Mock()

# Создаем объект, который мы будем тестировать
my_object = MyObject(mock_dependency)

# Имитируем поведение зависимости в мок-объекте
mock_dependency.some_method.return_value = 42

# Тестируем метод объекта
result = my_object.my_method("some argument")

# Проверяем, что метод объекта вызвал метод зависимости с правильным аргументом
mock_dependency.some_method.assert_called_once_with("some argument")

# Проверяем, что метод объекта вернул правильный результат
assert result == 42

Еще он умеет оборачивать существующую реализацию:

thing = ProductionClass()
thing.method = Mock(return_value=3)
thing.method(3, 4, 5, key="value")

thing.method.assert_called_with(3, 4, 5, key="value")

Преимущества и недостатки

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

Повсеместное использование моков приводит к двум вещам:

• После рефакторинга приходится переписывать тесты, даже если код работает правильно. Так происходит, потому что тесты завязаны на то, как конкретно работает код
• Код может перестать работать. При этом тесты будут проходить, потому что они сфокусированы не на результатах работы кода, а на его устройстве внутри

Там, где возможно использование реального кода — используйте реальный. Там, где возможно убедиться в работе кода без моков — делайте это без моков.

Излишний мокинг повышает стоимость поддержки тестов и делает их бесполезными. Идеальные тесты – тесты методом черного ящика.