Вы пишете:
как я могу протестировать модуль конфигурации [...] таким образом, чтобы изолировать его от его среды.
, но также
Я хочу проверить, что значения в файле совпадают с теми, которые были загружены в экземпляр конфигурации.
Что я понимаю следующим образом: Вы хотите проверитьцепочка «входные данные конфигурации» -> ConfigParser
-> Configuration
, чтобы проверить, будут ли «входные данные конфигурации» найдены в Configuration
ожидаемым образом.Между прочим, это скорее сценарий интеграционного тестирования, чем сценарий модульного тестирования.
Что касается упомянутой вами изоляции, я понимаю, что вы не хотите использовать «config.ini».в качестве источника данных, но то, что находится под вашим контролем.Вы уже предоставили имя файла конфигурации в качестве аргумента своему конструктору.Это хороший шаг, поскольку он дает вам некоторый контроль со стороны тестирования, а именно дает вам возможность указать файл, который будет использоваться из теста.
Однако вы можете даже пойти дальше:Класс 1020 * может читать из строки вместо файла (метод read_string
, новый в Python 3.2: https://docs.python.org/3/library/configparser.html). Если вы измените свой код таким образом, чтобы тест мог контролировать, дает ли Configuration
команду ConfigParser
для чтения из файла или из строки вы можете создавать свои интеграционные тесты, предоставляя в качестве входных данных строки, которые изолируют вас от файловой системы.
Существует множество способов изменить код, чтобы тесты могли сделатьон анализируется из строки, а не из файла: один простой способ - сделать объект ConfigParser
аргументом функции. Таким образом, вы извне создадите ConfigParser и либо прочитаете его из файла, либоиз строки. Другой вариант - выполнить чтение из вспомогательного метода, который вы можете переопределить в своем тесте.