Модификации файла поблочного тестирования

У Вас есть два уровня тестирования.

1. Фильтрация и Изменение содержания. Это операции "низкого уровня", которые действительно не требуют физического файлового ввода-вывода. Это тесты, принятие решений, альтернативы, и т.д. "Логика" приложения.

2. Операции файловой системы. Создайте, скопируйте, переименуйте, удалите, резервное копирование. Извините, но те - надлежащие операции файловой системы, которые - хорошо - требуют надлежащей файловой системы для тестирования.

Для этого вида тестирования, мы часто используем "Ложный" объект. Вы можете дизайн a класс "FileSystemOperations", который воплощает различные операции файловой системы. Вы тестируете это, чтобы быть уверенными, что это делает основное чтение, пишет, копирует, переименовывает и т.д. Нет никакой реальной логики в этом. Просто методы, которые вызывают операции файловой системы.

можно тогда создать MockFileSystem который макеты различные операции. Можно использовать этот Фиктивный объект для тестирования других классов.

В некоторых случаях, все Ваши операции файловой системы находятся в модуле OS. Если это так, можно создать модуль MockOS с ложной версией операций, которые Вы на самом деле используете.

Помещенный Ваш модуль MockOS на PYTHONPATH и можно скрыть реальный модуль ОС.

Для производственной деятельности Вы используете свои хорошо протестированные "Логические" классы плюс Ваш класс FileSystemOperations (или реальный модуль ОС.)

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

я сделал это в Java, и я предполагаю, что это довольно просто в Python..., но это может потребовать разработки Ваших классов/функций таким способом, которым ЛЕГКО дразнить использование фактического файла.

Для этого, можно попытаться передать в потоках и затем просто передать в потоке ввода/вывода простой строки, который не запишет в файл или иметь функцию, которая делает фактическую "запись, эта строка в файл" или "считала эту строку из файла", и затем заменяет ту функцию в тестах.

Я думаю, что Вы на правильном пути. В зависимости от того, что необходимо сделать , chroot может помочь Вам настроить среду для своего scrpits, который 'выглядит' реальным, но не является.

, Если это не работает тогда, Вы могли бы записать свои сценарии для взятия 'корневого' пути в качестве аргумента.

В массовом производстве корневой путь просто/. Для тестирования Вы создаете теневую среду под/tmp/test и затем выполняете Ваши сценарии с корневым путем/tmp/test.

Вы могли бы хотеть установить тест так, чтобы он работал в chroot тюрьме, таким образом, у Вас есть вся среда тестовые потребности, даже если пути и расположение файлов являются hardcoded в коде [не действительно хорошая практика, но иногда каждый получает расположение файлов от других мест...], и затем проверьте результаты через код выхода.

Для более поздних читателей, которым просто нужен способ проверить, что запись кода в файлы работает правильно, вот "fake_open", который исправляет встроенную встроенную функцию open модуля для использования StringIO. fake_open возвращает dict открытых файлов, которые можно проверить в модульном тесте или doctest, и все это без использования реальной файловой системы.

def fake_open(module):
    """Patch module's `open` builtin so that it returns StringIOs instead of
    creating real files, which is useful for testing. Returns a dict that maps
    opened file names to StringIO objects."""
    from contextlib import closing
    from StringIO import StringIO
    streams = {}
    def fakeopen(filename,mode):
        stream = StringIO()
        stream.close = lambda: None
        streams[filename] = stream
        return closing(stream)
    module.open = fakeopen
    return streams