У нас есть несколько методов, которые вызывают File.Copy, File.Delete, File.Exists и т. д. Как мы можем протестировать эти методы, не затрагивая файловую систему?
Я считаю себя юнит-тестером n00b, поэтому приветствую любые советы.
@ grieve - из того, что я читал, модульные тесты не должны попадать в файловую систему, базу данных или распространяться по сети. Я пытаюсь придерживаться этих правил.
Также см. stackoverflow.com/questions/106766/…
@ Джим: «Не попадайте в файловую систему» - это гибкое правило. До тех пор, пока вы можете быть уверены в том, что фиксация файловой системы согласована, обращение к файловой системе - это нормально. Обеспечение согласованности может быть не более чем сценарием восстановления в тестовом каталоге.





Если вам это абсолютно необходимо, Изолятор Typemock - ваш друг.
Я не могу сказать, что использовал его сам, и вместо этого я бы попытался разработать свой способ обойти его, но, насколько мне известно, он справится со своей задачей.
Как вы могли бы разработать свой способ обойти это?
@bovium: Нет, это коммерческий продукт.
@Jim: Ограничьте места, где он может взаимодействовать с файловой системой, и потенциально инкапсулирует взаимодействие файловой системы в интерфейсе. Вы можете либо использовать синглтон для файловой системы (и заменить его для тестирования - неприглядно, но не так плохо), либо использовать внедрение зависимостей.
Но в целом постарайтесь сделать так, чтобы большинство мест, которым нужны данные, принимали / производили их в виде потоков, читателей, писателей - не делайте ничего специфичного для файла, если это действительно, действительно должно быть.
Я опубликовал ответ, который иллюстрирует «проектирование вокруг» статического класса. На самом деле платформа должен предоставляет статический класс со статическими методами, и когда мы выполняем ООП, мы должен вызываем методы экземпляра на интерфейсах. Поэтому иногда нам нужно найти время, чтобы преодолеть разрыв.
+1 Для вашего подхода к дизайну - хороший «полный» ответ, возможно, будет включать что-то вроде примера Джастиса, показывающего интерфейсы, насмешки и инъекции зависимостей.
@David: Да, иногда у меня просто нет времени :(
Я бы используйте для этого Moq. Вам нужно будет создать интерфейс и класс, который будет прокси-сервером для реальной вещи, чтобы вы могли заставить Moq создать экземпляр вашего прокси (фиктивный экземпляр), но это лучший способ протестировать такие вещи.
Вы можете использовать для этого фиктивный фреймворк, который создаст поддельную копию объекта File, и вы сможете внедрить файл в тестируемую систему.
Я буду рекомендовать Rhino Mock.
Нет объекта File. Здесь мы говорим о статических методах. Вы можете разработать свой способ обойти это, как описано в комментариях к моему ответу, но это требует изменения.
public interface IFile {
void Copy(string source, string dest);
void Delete(string fn);
bool Exists(string fn);
}
public class FileImpl : IFile {
public virtual void Copy(string source, string dest) { File.Copy(source, dest); }
public virtual void Delete(string fn) { File.Delete(fn); }
public virtual bool Exists(string fn) { return File.Exists(fn); }
}
[Test]
public void TestMySystemCalls() {
var filesystem = new Moq.Mock<IFile>();
var obj = new ClassUnderTest(filesystem);
filesystem.Expect(fs => fs.Exists("MyFile.txt")).Return(true);
obj.CheckIfFileExists(); // doesn't hit the underlying filesystem!!!
}
В большинстве своих проектов я стараюсь создать интерфейс под названием IFileController, в котором есть все файловые операции. Это могут быть базовые методы, а также любые методы, которые .NET Framework не предоставляет для работы с файлами.
Используя фреймворк внедрения зависимостей, вы можете получить экземпляр IFileController, не зная точно, что это за тип, и использовать его без необходимости возиться с имитирующими типами фреймворка. Это делает все гораздо более тестируемым, а в качестве бонуса вы можете изменить механизм хранения файлов, вообще не меняя код.
С другой стороны, всем новым разработчикам нужно сообщить об этом интерфейсе, иначе они просто будут напрямую использовать методы .NET.
Я поддерживаю проект Jolt.NET на CodePlex, который содержит библиотеку для создания таких интерфейсов и их реализаций для вас. Пожалуйста, обратитесь к библиотеке Встряхивание. для получения дополнительной информации.
Что мешает вам попасть в файловую систему?