你如何在 C# 中模拟文件系统进行单元测试？

How do you mock out the file system in C# for unit testing?

提问by pupeno

Are there any libraries or methods to mock out the file system in C# to write unit tests? In my current case I have methods that check whether certain file exists and read the creation date. I may need more than that in future.

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

采纳答案by Matt Howells

Edit: Install the NuGet package System.IO.Abstractions.

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

This package did not exist when this answer was originally accepted. The original answer is provided for historical context below:

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

You could do it by creating an interface:

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

and creating a 'real' implementation which uses System.IO.File.Exists() etc. You can then mock this interface using a mocking framework; I recommend Moq.

Edit: somebody's done this and kindly posted it online here.

I've used this approach to mock out DateTime.UtcNow in an IClock interface (really really useful for our testing to be able to control the flow of time!), and more traditionally, an ISqlDataAccess interface.

Another approach might be to use TypeMock, this allows you to intercept calls to classes and stub them out. This does however cost money, and would need to be installed on your whole team's PCs and your build server in order to run, also, it apparently won't work for the System.IO.File, as it can't stub mscorlib.

You could also just accept that certain methods are not unit testable and test them in a separate slow-running integration/system tests suite.

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

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

并创建一个使用 System.IO.File.Exists() 等的“真实”实现。然后您可以使用模拟框架模拟此接口；我推荐起订量。

编辑：有人这样做了，并在此处在线发布。

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

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

您也可以接受某些方法不可单元测试并在单独的运行缓慢的集成/系统测试套件中测试它们。

回答by Jamie Ide

I'm not sure how you would mock up the file system. What you could do is write a test fixture setup that creates a folder, etc. with the necessary structure for the tests. A teardown method would clean it up after the tests run.

我不确定您将如何模拟文件系统。您可以做的是编写一个测试夹具设置，以创建一个文件夹等，其中包含测试所需的结构。一个拆卸方法会在测试运行后清理它。

Edited to add: In thinking about this a little more, I don't think you want to mock the file system to test this type of methods. If you mock the file system to return true if a certain file exists and use that in your test of a method that checks if that file exists, then you're not testing much of anything. Where mocking the file system would be useful is if you wanted to test a method that had a dependency on the file system but the file system activity was not integral to the method under test.

编辑补充：在多考虑这一点时，我认为您不想模拟文件系统来测试此类方法。如果您模拟文件系统以在某个文件存在时返回 true 并在测试检查该文件是否存在的方法中使用它，那么您没有测试任何内容。如果您想测试依赖于文件系统但文件系统活动不是被测方法不可或缺的方法，则模拟文件系统会很有用。

回答by Joseph

You're probably going to have to build a contract to define what things you need from the file system and then write a wrapper around those functionalities. At that point you'd be able to mock or stub out the implementation.

您可能必须建立一个契约来定义您需要从文件系统中获取哪些内容，然后围绕这些功能编写包装器。那时您将能够模拟或存根实现。

Example:

例子：

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

回答by LBushkin

It would be difficult to mock the file system in a test since the .NET file APIs are not really based on interfaces or extensible classes that could be mocked.

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

However, if you have your own functional layer to access the file system, you could mock that in a unit test.

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

As an alternative to mocking, consider just creating the folders and files you need as part of your test setup, and deleting them in your teardown method.

作为模拟的替代方法，考虑只创建您需要的文件夹和文件作为测试设置的一部分，并在拆卸方法中删除它们。

回答by gbanfill

I would go with Jamie Ide's response. Don't try to mock out things that you didn't write. There will be all manner of dependancies you didn't know about - sealed classes, non virtual methods etc.

我会同意 Jamie Ide 的回应。不要试图嘲笑不是你写的东西。会有各种你不知道的依赖关系——密封类、非虚拟方法等。

Another approach would be to wrap the appopiate methods with something that is mockable. e.g. create a class called FileWrapper that allows access to the File methods but is something you can mock out.

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

回答by akmad

To answer your specific question: No, there are no libraries that will allow you to mock file I/O calls (that I know of). This means that "properly" unit testing your types will require that you take this restriction into consideration when you define your types.

回答您的具体问题：不，没有任何库可以让您模拟文件 I/O 调用（我知道）。这意味着“正确”单元测试您的类型将要求您在定义类型时考虑此限制。

Quick side note about how I define a "proper" unit test. I believe that unit tests should confirm that you get the expected output (be that an exception, call on a method, etc) provided known inputs. This allows you to set up your unit test conditions as a set of inputs and/or input states. The best way I've found to do this is using interface-based services and dependency injection so that each responsibility external to a type is provided via an interface passed via a constructor or property.

关于我如何定义“正确”单元测试的快速旁注。我相信单元测试应该确认你得到了预期的输出（异常、方法调用等）提供了已知的输入。这允许您将单元测试条件设置为一组输入和/或输入状态。我发现这样做的最佳方法是使用基于接口的服务和依赖项注入，以便通过构造函数或属性传递的接口提供类型外部的每个责任。

So, with this in mind, back to your question. I've mocked file system calls by creating a IFileSystemServiceinterface along with a FileSystemServiceimplementation that is simply a facade over the mscorlib file system methods. My code then uses the IFileSystemServicerather than the mscorlib types. This allows me to plug in my standard FileSystemServicewhen the application is running or mock the IFileSystemServicein my unit tests. The application code is same regardless of how it's run, but the underlying infrastructure allows that code to be easily tested.

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

I'll acknowledge that it's a pain to use the wrapper around the mscorlib file system objects but, in these specific scenarios, it's worth the extra work as the testing becomes so much easier and more reliable.

我承认在 mscorlib 文件系统对象周围使用包装器很痛苦，但在这些特定场景中，值得做额外的工作，因为测试变得更加容易和可靠。

回答by Tien Do

We currently use a proprietary data engine and its API is not exposed as interfaces so we can hardly unit test our data access code. Then I went with Matt and Joseph's approach too.

我们目前使用专有的数据引擎，它的 API 没有作为接口公开，所以我们很难对我们的数据访问代码进行单元测试。然后我也采用了马特和约瑟夫的方法。

回答by Konamiman

Creating an interface and mocking it for testing is the cleanest way to go. However, as an alternative yo could take a look at the Microsoft Molesframework.

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

回答by Michael Lloyd Lee mlk

I've come across the following solutions to this:

我遇到了以下解决方案：

• Write Integration tests, not unit tests. For this to work you need a simple way of creating a folder where you can dump stuff without worrying about other tests interfering. I have a simple TestFolderclass which can create a unique per test method folder to use.
• Write a mockable System.IO.File. That is create a IFile.cs. I find using this often ends up with tests that simply prove you can write mocking statements, but do use it when the IO usage is small.
• Examine you layer of abstraction, and extract the file IO from the class. The create a interface for this. The remainder use integration tests (but this will be very small). This differs from above in that instead of doing file.Read you write the intent, say ioThingie.loadSettings()
• System.IO.Abstractions. I've not used this yet, but it is the one I'm most excited about playing with.

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

I end up using all the methods above, depending on what I'm writing. But most of the time I end up thinking abstraction is wrong when I write unit tests that hit the IO.

我最终使用了上述所有方法，这取决于我在写什么。但大多数时候，当我编写命中 IO 的单元测试时，我最终认为抽象是错误的。

回答by Binary Worrier

This imaginarylibrary exists now, there is a NuGet package for System.IO.Abstractions, which abstracts away the System.IO namespace.

这个虚构的库现在存在，有一个用于System.IO.Abstractions的 NuGet 包，它抽象出 System.IO 命名空间。

There is also a set of test helpers, System.IO.Abstractions.TestingHelpers which - at the time of writing - is only partially implemented, but is a very good starting point.

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