单元测试文件 I/O

测试文件系统时不一定要做一件事。事实上，根据具体情况，您可能会做几件事。

你需要问的问题是：我在测试什么？

文件系统有效吗？除非您使用的是您非常不熟悉的操作系统，否则您可能不需要对此进行测试。因此，例如，如果您只是发出保存文件的命令，那么编写测试以确保它们确实保存是浪费时间。

文件被保存到正确的位置？那么，你怎么知道正确的地方是什么？大概您有将路径与文件名组合在一起的代码。这是您可以轻松测试的代码：您的输入是两个字符串，您的输出应该是一个字符串，它是使用这两个字符串构造的有效文件位置。

您是否从目录中获得了正确的文件集？您可能必须为真正测试文件系统的文件获取器类编写测试。但是您应该使用包含不会更改文件的测试目录。您还应该将此测试放在集成测试项目中，因为这不是真正的单元测试，因为它依赖于文件系统。

但是，我需要对我得到的文件做一些事情。对于那个测试，你应该为你的文件获取器类使用一个假的。你的假货应该返回一个硬编码的文件列表。如果您使用真正的文件获取器和真正的文件处理器，您将不知道哪个导致测试失败。所以你的文件处理器类，在测试中，应该使用一个假的文件获取器类。您的文件处理器类应该采用文件获取器接口。在实际代码中，您将传入真正的文件获取器。在测试代码中，您将传递一个虚假的文件获取器，它返回一个已知的静态列表。

基本原则是：

当您不测试文件系统本身时，请使用隐藏在界面后面的假文件系统。

如果您需要测试真实的文件操作，则将测试标记为集成测试，而不是单元测试。有一个指定的测试目录、文件集等，它们将始终保持不变的状态，因此您的面向文件的集成测试可以始终如一地通过。

将测试标记为集成测试，而不是单元测试。

有一个指定的测试目录、文件集等，它们将始终保持不变的状态，因此您的面向文件的集成测试可以始终如一地通过。

---

使用 Rhino Mocks 和 SystemWrapper 查看 Tutorial to TDD。

SystemWrapper 包装了许多 System.IO 类，包括 File、FileInfo、Directory、DirectoryInfo 等。您可以看到 the complete list。

在本教程中，我将展示如何使用 MbUnit 进行测试，但它与 NUnit 完全相同。

您的测试将如下所示：

[Test]
public void When_try_to_create_directory_that_already_exists_return_false()
{
    var directoryInfoStub = MockRepository.GenerateStub<IDirectoryInfoWrap>();
    directoryInfoStub.Stub(x => x.Exists).Return(true);
    Assert.AreEqual(false, new DirectoryInfoSample().TryToCreateDirectory(directoryInfoStub));

    directoryInfoStub.AssertWasNotCalled(x => x.Create());
}

---

Q1：

你在这里有三个选择。

选项1：接受它。

（没有例子：P）

选项 2：在需要时创建一个轻微的抽象。

而不是在被测方法中执行文件 I/O（File.ReadAllBytes 或其他），您可以更改它以便在外部完成 IO 并传递流。

public class MyClassThatOpensFiles
{
    public bool IsDataValid(string filename)
    {
        var filebytes = File.ReadAllBytes(filename);
        DoSomethingWithFile(fileBytes);
    }
}

会成为

// File IO is done outside prior to this call, so in the level 
// above the caller would open a file and pass in the stream
public class MyClassThatNoLongerOpensFiles
{
    public bool IsDataValid(Stream stream) // or byte[]
    {
        DoSomethingWithStreamInstead(stream); // can be a memorystream in tests
    }
}

这种方法是一种权衡。首先，是的，它更具可测试性。但是，它牺牲了可测试性来稍微增加复杂性。这可能会影响可维护性和您必须编写的代码量，而且您可能只是将测试问题提高了一级。

但是，根据我的经验，这是一种很好的平衡方法，因为您可以概括并使重要逻辑可测试，而无需将自己提交给完全包装的文件系统。即，您可以概括您真正关心的部分，而将其余部分保持原样。

选项 3：包装整个文件系统

更进一步，模拟文件系统可能是一种有效的方法。这取决于你愿意忍受多少膨胀。

我以前走过这条路；我有一个打包的文件系统实现，但最后我只是删除了它。 API 有细微的差别，我不得不将它注入到任何地方，最终因为许多使用它的类对我来说并不是很重要，所以收获甚微。不过，如果我一直在使用 IoC 容器或编写一些关键的东西并且测试需要快速，我可能会坚持下去。与所有这些选项一样，您的里程可能会有所不同。

至于您的 IoC 容器问题：

手动注入您的测试替身。如果您必须做大量重复性工作，只需在测试中使用 setup/factory 方法即可。使用 IoC 容器进行测试将是极端的大材小用！不过，也许我不理解您的第二个问题。

---

我使用 System.IO.Abstractions NuGet 包。

这个网站有一个很好的例子，展示了如何使用注入进行测试。 http://dontcodetired.com/blog/post/Unit-Testing-C-File-Access-Code-with-SystemIOAbstractions

这是从网站复制的代码的副本。

using System.IO;
using System.IO.Abstractions;

namespace ConsoleApp1
{
    public class FileProcessorTestable
    {
        private readonly IFileSystem _fileSystem;

        public FileProcessorTestable() : this (new FileSystem()) {}

        public FileProcessorTestable(IFileSystem fileSystem)
        {
            _fileSystem = fileSystem;
        }

        public void ConvertFirstLineToUpper(string inputFilePath)
        {
            string outputFilePath = Path.ChangeExtension(inputFilePath, ".out.txt");

            using (StreamReader inputReader = _fileSystem.File.OpenText(inputFilePath))
            using (StreamWriter outputWriter = _fileSystem.File.CreateText(outputFilePath))
            {
                bool isFirstLine = true;

                while (!inputReader.EndOfStream)
                {
                    string line = inputReader.ReadLine();

                    if (isFirstLine)
                    {
                        line = line.ToUpperInvariant();
                        isFirstLine = false;
                    }

                    outputWriter.WriteLine(line);
                }
            }
        }
    }
}





using System.IO.Abstractions.TestingHelpers;
using Xunit;

namespace XUnitTestProject1
{
    public class FileProcessorTestableShould
    {
        [Fact]
        public void ConvertFirstLine()
        {
            var mockFileSystem = new MockFileSystem();

            var mockInputFile = new MockFileData("line1\nline2\nline3");

            mockFileSystem.AddFile(@"C:\temp\in.txt", mockInputFile);

            var sut = new FileProcessorTestable(mockFileSystem);
            sut.ConvertFirstLineToUpper(@"C:\temp\in.txt");

            MockFileData mockOutputFile = mockFileSystem.GetFile(@"C:\temp\in.out.txt");

            string[] outputLines = mockOutputFile.TextContents.SplitLines();

            Assert.Equal("LINE1", outputLines[0]);
            Assert.Equal("line2", outputLines[1]);
            Assert.Equal("line3", outputLines[2]);
        }
    }
}

---

自 2012 年以来，您可以使用 Microsoft Fakes 执行此操作，而无需更改您的代码库，例如因为它已经被冻结了。

首先 generate a fake assembly 用于 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
}

---

目前，我通过依赖注入使用 IFileSystem 对象。对于生产代码，包装类实现接口，包装我需要的特定 IO 功能。测试时，我可以创建一个 null 或 stub 实现并将其提供给被测类。被测试的班级并不聪明。

---