Теория: Инверсия зависимостей

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

Как избежать побочных эффектов в тестировании

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

params = {
    "email": "lala@example.com",
    "password": "qwerty",
}
register_user(params)

Эта функция делает много всего, но главное, что нас волнует – правильная регистрация пользователя. Типичная регистрация сводится к добавлению в базу данных записи о новом пользователе. Именно это и нужно проверять – наличие новой записи в базе данных с правильно заполненными данными. А вот возврат функции нам никак не поможет.

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

# Гипотетический пример

# Соединение с базой создается один раз на весь запуск тестов
@pytest.fixture(scope="session")
def connection():
    engine = create_engine(
        # тут параметры соединения
    )
    return engine.connect()


# Транзакция стартует и откатывается на каждый тест
@pytest.fixture(autouse=True)
def transaction(connection):
    connection.begin()
    yield
    connection.rollback()


# Сам тест
def test_register_user():
    # Внутри идет добавление данных в базу
    id = register_user(name="Mike")
    # Извлекаем пользователя из базы
    user = User.objects.get(id)
    assert user.name == "Mike"

А вот с отправкой писем все сложнее. Ее точно делать нельзя, но как этого добиться? Посмотрите, как может выглядеть функция регистрации пользователя:

def register_user(**params):
    user = User(**params)
    user.save()
    send_email("registration", user)
    return user.id

Существует несколько подходов, позволяющих отключить отправку в тестах.

Самый простой способ — переменная окружения, которая показывает среду выполнения:

# Выполняем этот код, только если мы не в тестовой среде
# Имя переменной может быть любым
if os.environ["PROJECT_ENV"] != "test":
    send_email("registration", user)

Несмотря на простоту использования, такой подход считается плохой практикой. Формально, из-за него происходит нарушение абстракции — код начинает знать, где он выполняется. Со временем таких проверок становится все больше, код становится грязнее. Более того, если нам все же надо убедиться, что письмо отправляется с правильными данными, то мы не сможем этого сделать.

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

# представим, что наша библиотека отправки писем позволяет такой режим
from mailer import send_email

# До выполнения тестов
mailer.test = True

Теперь в любом другом месте, где импортируется и используется функция send_email(), реальная отправка происходить не будет:

# Ничего не происходит
send_email("registration", user)
# В отличие от варианта с переменной окружения,
# в этом случае прикладной код ни о чем не догадывается

Это довольно популярное решение в некоторых языках. Обычно информация о том, как правильно включить режим тестирования, находится в официальной документации конкретной библиотеки. Но что делать, если используемая библиотека не поддерживает режим тестирования?

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

from mailer import send_email


# Ставим значение по умолчанию, чтобы не пришлось постоянно указывать функцию
def register_user(send=send_email, **params):
    user = User(**params)
    user.save()
    send("registration", user)
    return user.id

Затем в тестах мы создадим заглушку, функцию, которую передадим вместо реальной:

def fake_send_email(*args, **kwargs):
    # Например, письмо можно вывести в терминал для удобства отладки
    print(*args, **kwargs)


def test_register_user():
    # В тестах подменяем функцию отправки на нашу заглушку
    id = register_user(name="Mike", send=fake_send_email)
    user = User.objects.get(id)
    assert user.name == "Mike"

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

Теперь обсудим плюсы. Ни библиотека, ни код ничего не знают про тесты. Этот способ наиболее гибкий, он позволяет задавать конкретное поведение для конкретной ситуации. В некоторых экосистемах существуют системы инверсии зависимостей, как контейнер зависимостей, которые определяют процесс сборки приложения. Особенно в мире PHP, Java и C#.

Кстати, pytest-фикстуры это пример контейнера зависимостей в экосистеме Python. Для использования фикстуры в тесте, она указывается в параметрах во время определения теста. А уже во время запуска тестов pytest самостоятельно выполняет фикстуры и прокидывает их в нужные нам функции.