Python: Продвинутое тестирование
2026-02-26 16:43 Diff
https://ru.hexlet.io/courses/python-advanced-testing/lessons/elimination-of-side-effects/theory_unit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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