Как Вы дразните файловую систему в C# для поблочного тестирования?

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

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

Было бы сложно имитировать файловую систему в тесте, поскольку файловые API .NET на самом деле не основаны на интерфейсах или расширяемых классах, которые можно было бы имитировать.

Однако,

Чтобы ответить на ваш конкретный вопрос: Нет, нет библиотек, которые позволили бы вам имитировать вызовы файлового ввода-вывода (о которых я знаю). Это означает, что «правильное» модульное тестирование ваших типов потребует, чтобы вы приняли это ограничение во внимание при определении ваших типов.

Краткое примечание о том, как я определяю «правильный» модульный тест. Я считаю, что модульные тесты должны подтвердить, что вы получаете ожидаемый результат (будь то исключение, вызов метода и т. Д.) При условии известных входных данных. Это позволяет вам настроить условия модульного тестирования как набор входов и / или входных состояний. Наилучший способ, который я нашел для этого, - использование сервисов на основе интерфейса и внедрения зависимостей, так что каждая ответственность, внешняя по отношению к типу, предоставляется через интерфейс, передаваемый через конструктор или свойство.

Итак, имея это в виду, вернемся к вашему вопросу. Я имитировал вызовы файловой системы, создав интерфейс IFileSystemService вместе с реализацией FileSystemService , которая является просто фасадом над методами файловой системы mscorlib. Затем в моем коде используется IFileSystemService , а не типы mscorlib. Это позволяет мне подключать стандартную FileSystemService , когда приложение работает, или имитировать IFileSystemService в моих модульных тестах. Код приложения один и тот же независимо от того, как оно выполняется, но базовая инфраструктура позволяет легко протестировать этот код.

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

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

Пример:

interface IFileWrapper { bool Exists(String filePath); }

class FileWrapper: IFileWrapper
{
    bool Exists(String filePath) { return File.Exists(filePath); }        
}

class FileWrapperStub: IFileWrapper
{
    bool Exists(String filePath) 
    { return (filePath == @"C:\myfilerocks.txt"); }
}

Я бы согласился с ответом Джейми Айдэ. Не пытайтесь высмеивать то, чего не писали. Появятся всевозможные зависимости, о которых вы не знали - запечатанные классы, невиртуальные методы и т. Д.

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

В настоящее время мы используем проприетарный механизм обработки данных, и его API не представлен в виде интерфейсов, поэтому мы вряд ли сможем провести модульное тестирование нашего кода доступа к данным. Тогда я тоже согласился с подходом Мэтта и Джозефа.

Создание интерфейса и имитация его для тестирования - самый чистый путь. Однако в качестве альтернативы вы можете взглянуть на фреймворк Microsoft Moles .

Я нашел следующие решения этой проблемы:

• Пишите тесты интеграции, а не модульные тесты. Чтобы это работало, вам нужен простой способ создания папки, в которую вы можете выгружать данные, не беспокоясь о том, что другие тесты будут мешать. У меня есть простой класс TestFolder , который может создать уникальную папку для каждого метода тестирования.
• Напишите имитацию System.IO.File. То есть создать IFile.cs . Я нахожу, что использование этого часто заканчивается тестами, которые просто доказывают, что вы можете писать насмешливые операторы, но действительно используйте его, когда использование ввода-вывода невелико.
• Изучите уровень абстракции и извлеките файл ввода-вывода из класса. Создайте для этого интерфейс. Остальные используют интеграционные тесты (но это будет очень мало). Это отличается от приведенного выше тем, что вместо file.Read вы пишете намерение, скажем, ioThingie.loadSettings ()
• System.IO.Abstractions . Я еще не использовал это, но мне больше всего нравится играть с ним.

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