Тестирование модуля со сложной структурой каталогов

Question

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

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

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

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

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

Answer 1

У этого есть перспектива 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 2

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

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

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

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

Answer 3

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

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

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

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

Roy Osherove говорит в Art of Unit Testing, что отличная идея поддерживать и обновлять тестовый код при сохранении и версии вашего проекта.

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

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

Answer 4

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