Добрый вечер. есть модуль, который активно взаимодействует с БД. я пишу

для него подобие интеграционных тестов.

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

from some.module import SomeClass
original_method = SomeClass.method

def patched_method(self, *args, **kwargs):
if should_throw(*args, **kwags):
raise Exception('whatever')

return original_method(self, *args, **kwargs)

и далее:

with mock.patch('some.module.SomeClass.method', new=patched_method):
... собственно тест...

меня устраивает результат, но я хочу более изящное решение. есть какие-то варианты?

DI + repository pattern

про DI - в смысле, подсунуть аргументом объект, который будет выбрасывать исключение в нужный момент? я думал об этом, но я дергаю API самого верхнего уровня, чтобы было максимально похоже на черный ящик. у него аргументы только примитивы (строка/число), внедрить нечего. про reporsitory pattern почитаю.

У апи верхнего уровня должно быть место куда внедряются элементы более низкого

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

Если ты тестируешь целиком, значит БД для тебя несуществует и является частью реализации

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

Тогда я хочу уточнить. Смысл работы модуля: делать операции с БД или делать какую-то бизнес логику?

в данном конкретном случае задача - вынуть данные из одного места и загрузить в другое, предварительно что-то с ними сделав. для простоты - ETL (это одна частная задача; есть другие). т.е. требуемые конечный результат - это данные в нужной мне БД в нужном мне виде. работа с БД это и есть бизнес-логика. по второму вопросу - я внедряюсь грязно с верхнего уровня, потому что не могу внедриться чисто с него же. внедриться чисто - чище - на слой ниже можно - он дергает более низкоуровневые апи, в которых более или менее поддерживается DI - но кроме этих апи он делает еще некоторые вещи, которые мне придется воспроизвести в тесте для получаения конечного результата. это задача на рефакторинг позднее.

Внедряться грязно - ещё хуже чем просто внедряться. Потому что в этом случае ты используешь детали реализации, а не специально предусмотренное место

хорошо, допустим. в итоге что? не писать тест до рефакторинга, пока я не смогу обеспечить чистое внедрение? я хотел ровно наоборот - иметь хоть как-то покрытый тестами модуль, чтобы быть уверенным, что мой рефакторинг его не сломает.

Тогда у тебя нет вариантов

А ты не можешь воспроизвести эти "отказы" средствами самой бд?