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

Это имеет перспективу 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 похоже.

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

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

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

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

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

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

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

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

Рой Ошеров говорит в The Art of Unit Testing, что это отличная идея — поддерживать и версионировать тестовый код по мере того, как поддерживается и версионируется ваш проект.

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

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

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