您如何在C＃中模拟文件系统以进行单元测试？

是否有任何库或方法可以模拟C＃中的文件系统以编写单元测试？在我目前的情况下，我有一些方法来检查某些文件是否存在并读取创建日期。将来我可能会需要更多。

编辑：安装NuGet软件包System.IO.Abstractions。

最初接受此答案时，此软件包不存在。以下是针对历史背景提供的原始答案：

您可以通过创建接口来做到这一点：

interface IFileSystem {
    bool FileExists(string fileName);
    DateTime GetCreationDate(string fileName);
}

然后创建一个使用System.IO.File.Exists（）等的“真实”实现。我建议起订量。

编辑：有人完成了此操作，请在此处在线发布。

我已经使用这种方法在IClock接口中模拟出DateTime.UtcNow（对我们的测试来说非常有用，它能够控制时间流！），更传统地，是ISqlDataAccess接口。

另一种方法是使用TypeMock，它允许您拦截对类的调用并将其存根。但是，这确实要花钱，并且需要在整个团队的PC和构建服务器上安装才能运行，而且，它显然不能用于System.IO.File，因为它无法对mscorlib进行存根处理。

您还可以接受某些方法不可单元测试，并在一个单独的运行缓慢的集成/系统测试套件中对其进行测试。

这个虚构的库现已存在，其中有一个用于System.IO.Abstractions的NuGet程序包，该程序包抽象了System.IO命名空间。

还有一组测试助手System.IO.Abstractions.TestingHelpers-在撰写本文时，仅部分实现，但这是一个很好的起点。

您可能必须建立一个合同来定义文件系统需要什么，然后围绕这些功能编写包装器。到那时，您将可以模拟或存根实现。

例：

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"); }
}

我的建议是使用http://systemwrapper.codeplex.com/， 因为它为System名称空间中最常用的类型提供了包装器

我遇到了以下解决方案：

• 编写集成测试，而不是单元测试。为此，您需要一种简单的方法来创建一个文件夹，在其中可以转储内容而无需担心其他测试的干扰。我有一个简单的TestFolder类，该类可以为每个测试方法文件夹创建一个唯一的要使用的文件夹。
• 编写一个可模拟的System.IO.File。那就是创建一个IFile.cs。我发现使用它的结果通常是测试，这些测试仅证明您可以编写模拟语句，但是在IO使用量较小时才使用它。
• 检查您的抽象层，并从类中提取文件IO。为此创建一个接口。其余的使用集成测试（但这将很小）。这与上面的不同之处在于它不是执行文件操作，而是编写意图，例如ioThingie.loadSettings（）
• System.IO.Abstractions。我还没有使用过，但是这是我最兴奋的玩法。

我最终使用上面的所有方法，具体取决于我在写什么。但是大多数时候，当我编写影响IO的单元测试时，我总是以为抽象是错误的。

通过使用像这样的System.IO.Abstractions和System.IO.Abstractions.TestingHelpers：

public class ManageFile {
   private readonly IFileSystem _fileSystem;
   public ManageFile(IFileSystem fileSystem){

      _fileSystem = fileSystem;
   }

   public bool FileExists(string filePath){}
       if(_fileSystem.File.Exists(filePath){
          return true;
       }
       return false;
   }
}

在测试类中，使用MockFileSystem（）模拟文件，然后实例化ManageFile，如下所示：

var mockFileSysteme = new MockFileSystem();
var mockFileData = new MockFileData("File content");
mockFileSysteme.AddFile(mockFilePath, mockFileData );
var manageFile = new ManageFile(mockFileSysteme);

您可以使用Microsoft Fakes进行此操作，而无需更改代码库，例如，因为它已被冻结。

首先为System.dll-或任何其他软件包生成一个假程序集，然后模拟期望的回报，如下所示：

using Microsoft.QualityTools.Testing.Fakes;
...
using (ShimsContext.Create())
{
     System.IO.Fakes.ShimFile.ExistsString = (p) => true;
     System.IO.Fakes.ShimFile.ReadAllTextString = (p) => "your file content";

      //Your methods to test
}

在测试中很难模拟文件系统，因为.NET文件API并不是真正基于可以模拟的接口或可扩展类。

但是，如果您拥有自己的功能层来访问文件系统，则可以在单元测试中对此进行模拟。

作为模拟的替代方法，请考虑仅在测试设置中创建所需的文件夹和文件，然后在拆卸方法中将其删除。

我不确定您将如何模拟文件系统。您可以做的是编写一个测试装置设置，该创建一个具有测试所需结构的文件夹等。测试运行后，拆解方法将清除它。

编辑添加：在考虑这一点时，我认为您不想模拟文件系统来测试这种类型的方法。如果您模拟文件系统以在某个文件存在的情况下返回true，并在测试该文件是否存在的方法的测试中使用该文件系统，则您无需进行太多测试。如果您想测试依赖于文件系统的方法，但是文件系统活动不是被测试方法所不可或缺的，那么模拟文件系统将很有用。

要回答您的特定问题：不，没有库可让您模拟文件I / O调用（据我所知）。这意味着“适当地”对类型进行单元测试将要求您在定义类型时考虑此限制。

关于如何定义“适当”单元测试的简要说明。我相信单元测试应该确认您提供了已知输入，从而获得了预期的输出（例如，异常，调用方法等）。这使您可以将单元测试条件设置为一组输入和/或输入状态。我发现执行此操作的最佳方法是使用基于接口的服务和依赖项注入，以便通过构造函数或属性传递的接口来提供类型外部的每个职责。

因此，考虑到这一点，请回到您的问题。我通过创建一个IFileSystemService接口以及一个FileSystemService实现（它只是mscorlib文件系统方法的基础）来模拟文件系统调用。然后，我的代码使用IFileSystemService而不是mscorlib类型。这使我可以在FileSystemService应用程序运行时插入标准，或IFileSystemService在单元测试中模拟。无论其运行方式如何，应用程序代码都是相同的，但是底层基础结构允许对该代码进行轻松测试。

我会承认，在mscorlib文件系统对象周围使用包装器是很痛苦的，但是，在这些特定情况下，由于测试变得更加容易和可靠，因此值得进行额外的工作。

创建接口并对其进行模拟以进行测试是最干净的方法。但是，作为替代方案，您可以看看Microsoft Moles框架。

常见的解决方案是使用一些抽象的文件系统API（例如Apache Commons VFS for Java）：所有应用程序逻辑都使用API​​，并且单元测试能够通过存根实现（内存中仿真或类似的东西）模拟真实的文件系统。

对于C＃，存在类似的API：NI.Vfs，它与Apache VFS V1非常相似。它包含本地文件系统和内存文件系统的默认实现（可以从框中选择最后一个在单元测试中使用）。

当前，我们使用专有的数据引擎，并且其API并未公开为接口，因此我们几乎无法对数据访问代码进行单元测试。然后我也接受了马特和约瑟夫的方法。

我同意杰米·艾德的回答。不要试图嘲笑您没有写的东西。您将不知道有各种各样的依赖关系-密封类，非虚拟方法等。

另一种方法是用一些可模拟的东西来包装appopiate方法。例如，创建一个名为FileWrapper的类，该类允许访问File方法，但是您可以模拟一下。