Как разрешить переключение на (nullable) инфраструктурные заглушки в Django
Вопрос - Какой подход или паттерн проектирования позволит легко использовать в Django заглушки для внешних интеграций при выполнении тестов? Под "внешними интеграциями" я подразумеваю пару внешних REST API, и файловую систему NAS. Внешние интеграции уже являются отдельными модулями/классами.
Что я делаю сейчас -
В настоящее время я отключаю внешние зависимости в тестах, в основном рассыпая утверждения mock.path() по всему тестовому коду.
Но это становится непрактичным (нужно применять каждый тест; также легко забыть, особенно в высокоуровневых тестах), и слишком много связано с внутренним устройством некоторых модулей.
Некоторые детали того, что я ищу
Мне нравится концепция "обнуляемой инфраструктуры", описанная на сайте https://www.jamesshore.com/v2/blog/2018/testing-without-mocks#nullable-infrastructure.
Я особенно ищу подход, который хорошо интегрируется с Django, т.е. учитывая подход settings.py к файлам, и запуск тестов через python manage.py test.
Я хотел бы иметь возможность легко:
- заявить, что все тесты должны использовать нуллифицируемый аналог класса или функции инфраструктуры .
- переопределять это поведение для каждого теста или класса теста, когда это необходимо (например, при тестировании реальной внешней инфраструктуры). .
Я попробовал подход, описанный в https://medium.com/analytics-vidhya/mocking-external-apis-in-django-4a2b1c9e3025, где в основном говорится о создании реализации интерфейса, реальной реализации и реализации-заглушки. Переключение осуществляется с помощью декоратора класса. Но это не очень хорошо работает: декоратор классов в моей установке не работает с @override_settings (декоратор применяет настройки при запуске django, а не при выполнении теста), и там действительно много лишнего кода (который также кажется непитоническим).