Разработка через тестирование: хороший / приемлемый способ тестирования операций файловой системы?

В данный момент я работаю над проектом, который генерирует таблицу (помимо прочего) на основе содержимого файловой системы и, в свою очередь, вносит некоторые изменения в метаданные относительно обнаруженных ею вещей. Вопрос в том, как обдумать или настроить тесты? Есть ли простой способ сделать это? Или я должен установить «песочницу»?

Как вы всегда делаете в TDD с внешними ресурсами: вы создаете один или несколько интерфейсов для операций вашей файловой системы и «макете их». Вы хотите проверить свой «генератор таблиц» и код модификации метаданных, а не сами операции файловой системы (скорее всего, вы используете готовые реализации библиотек для доступа к файловой системе).

Что плохого в том, чтобы иметь «тестовую» файловую систему?

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

Во время настройки вашего тестового модуля скопируйте эту исходную структуру (рекомендую вам заархивировать шаблон и распаковать его в тестовую область). Запустите ваши тесты. Удалите все это во время сноса.

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

Это именно то, что вам определенно необходимо для тестирования интеграции, поскольку в реальных файловых системах наблюдается довольно странное поведение (например, из-за того, что Windows не позволяет удалять файл, если какой-либо процесс, включая средство удаления, открывает его).

Таким образом, подход TDD заключается в том, чтобы сначала написать интеграционный тест (строго говоря, TDD не имеет четких понятий «модульный тест» и «интеграционный тест»; это всего лишь тесты). Вполне вероятно, что этого будет достаточно; так что работа сделана, остановись, иди домой .

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

Ни в коем случае вы бы не взяли основное ядро ​​кода, который вы пишете, и «смоделировали» его, чтобы написать тесты, которые пройдут независимо от того, является ли тестируемый модуль неправильным.

Я понимаю ваш вопрос как «Хороший / приемлемый способ тестирования класса, который зависит от операций файловой системы». Я не предполагаю, что вы хотите проверить файловую систему вашей ОС.

Чтобы сохранить «интерфейс к операциям вашей файловой системы и« макетировать их »», как подсказывает ответ @Doc Brown, как можно меньше, полезно использовать двоичные потоки Java или средство чтения текста (или их эквивалент в c # или язык программирования, который вы используете) вместо использования файлов с именами файлов непосредственно в вашем tdd-разработанный класс.

Пример:

Используя Java, я реализовал класс CsvReader

public class CsvReader {
    private Reader reader;

    public CsvReader(Reader reader) {
        this.reader = reader;
    }
}

Для тестирования я использовал в памяти такие данные

String contentOfCsv = "TestColumn1;TestColumn2\n"+
    "value1;value2\n";

CsvReader sut = new CsvReader(java.io.StringReader(contentOfCsv));

или встроить тестовые данные в ресурсы

CsvReader sut = new CsvReader(getClass().getResourceAsStream("/data.csv"));

В производстве я использую файловую систему

CsvReader sut = new CsvReader(new BufferedReader( new FileReader( "/import/Prices.csv" ) ));

Таким образом, мой CsvReader зависит не от файловой системы, а от абстракции «Reader», где есть реализация для файловой системы.

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