При увеличении охвата кода и тестируемости собственной разработанной среды существует специфическая c проблема, когда речь идет об импортированных модулях.
Скажем, модуль выглядит следующим образом:
(по унаследованным и другим причинам общая настройка фреймворка не обсуждается :))
from Toolkits import some_toolkit
Class X(object):
def __init__():
# this toolkit interfaces with a legacy system
self.toolkit_instance = some_toolkit()
def run():
# do some stuff with info from the toolkit instance
Этот класс создается фреймворком, если выполняются определенные условия и функция run
Теперь я хочу протестировать logi c в этой функции run
и подумать над этим:
from Toolkits import some_toolkit
Class X(object):
def __init__():
# this toolkit interfaces with a legacy system
self.toolkit = some_toolkit
def run():
self.toolkit_instance = self.toolkit()
# do some stuff with info from the toolkit instance
Что позволило бы мне создать экземпляр класса в моем тесте, патче self.toolkit
с фиктивным модулем, содержащим необходимые мне тестовые данные, и проверьте лог c в функции run
.
Причина, по которой я не исправляю сам импорт, связана с кэшированием импорта на Python. IRL создание экземпляра импортированного инструментария будет отражать состояние во внешней системе, и для другого сценария тестирования ios я хочу, чтобы импорт отражал различные состояния. Параметризация их приводит к нежелательным результатам (первый экземпляр всегда используется тестируемым объектом), что приводит меня к этому решению. Есть ли что-то против такого решения, и я упускаю очевидное другое (надеюсь, элегантное) решение?