Модульное тестирование со сложной структурой каталогов

Question

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

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

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

Я понимаю, как выполнить модульное тестирование операций ввода-вывода, но как мне выполнить модульное тестирование такого сценария?

Edit: Мне не нужно будет на самом деле читать файлы. Приложению необходимо проанализировать структуру каталогов и определить, какие файлы существуют в нем. И это большое количество подкаталогов с большим количеством файлов.

Answer 1

Я бы определил набор интерфейсов, имитирующих файловую систему , таких как IDirectory и IFile, а затем использовал бы Test Doubles для создания представления каталога структура в памяти.

Это позволит вам провести модульное тестирование (и изменить) эту структуру в соответствии с вашим сердцем.

Вам также потребуются конкретные реализации, которые реализуют эти интерфейсы с использованием реальных классов BCL для этой цели.

Это позволяет вам изменять структуру данных и доступ к данным независимо друг от друга.

Answer 2

Это имеет перспективу Python. Возможно, вы не работаете в Python, но ответ более или менее применим к большинству языков.

При модульном тестировании с любым внешним ресурсом (например, модулем os) вы должны макетировать внешний ресурс.

Вопрос в том, "как сделать макет os.walk?" (или os.listdir или что вы используете.)

1. Напишите имитационную версию функции. os.walk например. Каждая макетная версия возвращает список каталогов и файлов, чтобы вы могли использовать свое приложение.

   Как это построить?

   Напишите «сборщик данных», который выполняет os.walk для реальных данных и создает большой старый список ответов, которые вы можете использовать для тестирования.

2. Создание фиктивной структуры каталогов. «было бы больно писать код для репликации существующей структуры каталогов», обычно это не так. Модифицированная структура каталогов представляет собой простой список имен. Там нет боли вообще.

Учтите это

def setUp( self ):
    structure= [ 
        "/path/to/file/file.x", 
        "/path/to/another/file/file.y", 
        "/some/other/path/file.z",...
    ]
    for p in structure:
        path, file = os.path.split( p )
        try:
            os.makedirs( path )
        except OSError:
            pass
        with open( p, "w" ) as f:
            f.write( "Dummy Data" )

Это все, что требуется для setUp. tearDown похоже.

Answer 3

Вот так, это звучит как зверь.Я сам баловался тестированием.

Похоже, что основной вопрос вашего вопроса звучит так: «Как мне настроить большое количество файлов, чтобы я мог тестировать методы, которые проверяют, существуют ли эти файлы?»

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

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

Рой Ошеров говорит в Искусство модульного тестирования , чтоОтличная идея - поддерживать и проверять ваш тестовый код по мере того, как ваш проект поддерживается и поддерживается версия.

Я думаю, что для согласованности было бы целесообразно создать некоторые фиктивные данные и поместить их в какой-либо источникуправляйте репозиторием с вашим тестовым кодом.Таким образом, вы можете упростить процесс копирования фиктивных данных на другой компьютер и не беспокоиться о том, чтобы отслеживать, какие фиктивные данные находятся на каком компьютере.Это было бы больно!

Мое решение: поместить фиктивные данные в систему контроля источников.

Answer 4

Возможным решением было бы создание фиктивной структуры файлов и каталогов из файла tar, который развертывает ваш метод установки.