具有文件系统依赖性的单元测试代码

我正在编写一个组件，给定一个ZIP文件，该组件需要：

1. 解压缩文件。
2. 在解压缩的文件中找到一个特定的dll。
3. 通过反射加载该dll并在其上调用方法。

我想对该组件进行单元测试。

我很想编写直接处理文件系统的代码：

void DoIt()
{
   Zip.Unzip(theZipFile, "C:\\foo\\Unzipped");
   System.IO.File myDll = File.Open("C:\\foo\\Unzipped\\SuperSecret.bar");
   myDll.InvokeSomeSpecialMethod();
}

但是人们经常说：“不要编写依赖于文件系统，数据库，网络等的单元测试。”

如果我以对单元测试友好的方式编写此代码，我想它看起来应该像这样：

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

好极了！现在可以测试了；我可以将测试双打（模拟）输入DoIt方法。但是要花多少钱呢？我现在必须定义3个新接口才能使其可测试。我到底在测试什么？我正在测试我的DoIt函数与其依赖项正确交互。它无法测试zip文件是否已正确解压缩，等等。

感觉好像我不再在测试功能。感觉就像我只是在测试课堂互动。

我的问题是：对依赖于文件系统的内容进行单元测试的正确方法是什么？

编辑我正在使用.NET，但是该概念也可以应用Java或本机代码。

这样做确实没有错，这只是您将其称为单元测试还是集成测试的问题。您只需要确保与文件系统进行交互就不会有意外的副作用。具体而言，请确保自己清理后-删除创建的所有临时文件-并且不要意外覆盖与文件名相同的现有文件。始终使用相对路径，而不要使用绝对路径。

chdir()在运行测试之前进入临时目录，然后再chdir()返回，这也是一个好主意。

好极了！现在可以测试了；我可以将测试双打（模拟）输入DoIt方法。但是要花多少钱呢？我现在必须定义3个新接口才能使其可测试。我到底在测试什么？我正在测试我的DoIt函数与其依赖项正确交互。它无法测试zip文件是否已正确解压缩，等等。

您已经碰到了它的头。您要测试的是方法的逻辑，不一定要确定是否可以处理真实文件。您不需要测试（在此单元测试中）文件是否已正确解压缩，您的方法将其视为理所当然。这些接口本身很有价值，因为它们提供了您可以针对其进行编程的抽象，而不是隐式或显式地依赖于一种具体的实现。

您的问题向刚接触开发人员的测试暴露了最困难的部分之一：

“我到底要测试什么？”

您的示例不是很有趣，因为它只是将一些API调用粘合在一起，因此，如果您要为其编写单元测试，则最终只能断言方法已被调用。像这样的测试将您的实现细节与测试紧密结合在一起。这很不好，因为现在每次更改方法的实现细节都必须更改测试，因为更改实现细节会破坏您的测试！

实际上，进行不良测试比根本不进行测试更糟糕。

在您的示例中：

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

尽管您可以传递模拟，但测试方法中没有逻辑。如果要对此进行单元测试，它可能看起来像这样：

// Assuming that zipper, fileSystem, and runner are mocks
void testDoIt()
{
  // mock behavior of the mock objects
  when(zipper.Unzip(any(File.class)).thenReturn("some path");
  when(fileSystem.Open("some path")).thenReturn(mock(IFakeFile.class));

  // run the test
  someObject.DoIt(zipper, fileSystem, runner);

  // verify things were called
  verify(zipper).Unzip(any(File.class));
  verify(fileSystem).Open("some path"));
  verify(runner).Run(file);
}

恭喜，您基本上将DoIt()方法的实现细节复制粘贴到了测试中。维护愉快。

当你写测试，要考什么，而不是如何。 有关更多信息，请参见黑匣子测试。

在什么是你的方法的名称（或至少应该是）。该如何为所有的小细节时住在你的方法内。良好的测试让你换出如何不破坏什么。

这样考虑一下，问自己：

“如果我更改此方法的实现细节（而不更改公共合同），是否会破坏我的测试？”

如果答案是肯定的，你正在测试的如何，而不是什么。

为了回答有关测试具有文件系统依赖性的代码的特定问题，假设您对文件进行了一些更有趣的操作，并且想要将Base64编码的内容保存byte[]到文件中。您可以使用流为这个来测试你的代码做正确的事，而不必检查怎么它做它。一个示例可能是这样的（在Java中）：

interface StreamFactory {
    OutputStream outStream();
    InputStream inStream();
}

class Base64FileWriter {
    public void write(byte[] contents, StreamFactory streamFactory) {
        OutputStream outputStream = streamFactory.outStream();
        outputStream.write(Base64.encodeBase64(contents));
    }
}

@Test
public void save_shouldBase64EncodeContents() {
    OutputStream outputStream = new ByteArrayOutputStream();
    StreamFactory streamFactory = mock(StreamFactory.class);
    when(streamFactory.outStream()).thenReturn(outputStream);

    // Run the method under test
    Base64FileWriter fileWriter = new Base64FileWriter();
    fileWriter.write("Man".getBytes(), streamFactory);

    // Assert we saved the base64 encoded contents
    assertThat(outputStream.toString()).isEqualTo("TWFu");
}

该测试使用ByteArrayOutputStream，但在应用程序（使用依赖注入）的实际StreamFactory（也许叫FileStreamFactory）将返回FileOutputStream距离outputStream()，并会写入File。

write这里的方法有趣的是，它是将内容写成Base64编码的，因此我们对此进行了测试。对于您的DoIt()方法，将使用集成测试对其进行更适当的测试。

我不愿使用仅用于促进单元测试的类型和概念来污染我的代码。当然，如果它可以使设计更干净，更好，那就更好了，但我认为通常并非如此。

我对此的看法是，您的单元测试将尽其所能，这可能不是100％的覆盖率。实际上，可能只有10％。关键是，您的单元测试应该快速并且没有外部依赖性。他们可能会测试类似“这种方法，当您为此参数传入null时，此方法将引发ArgumentNullException”。

然后，我将添加可以具有外部依赖性并测试诸如此类的端到端方案的集成测试（也是自动化的，并且可能使用相同的单元测试框架）。

在测量代码覆盖率时，我同时测量单元测试和集成测试。

命中文件系统没有任何问题，只需将其视为集成测试而不是单元测试即可。我将硬编码路径与相对路径交换，并创建一个TestData子文件夹以包含单元测试的zip。

如果您的集成测试花费的时间太长，请把它们分开，这样它们就不会像您的快速单元测试那样频繁地运行。

我同意，有时我认为基于交互的测试可能会导致过多的耦合，并且常常最终无法提供足够的价值。您确实要在这里测试将文件解压缩，而不仅仅是验证您在调用正确的方法。

一种方法是编写解压缩方法以获取InputStreams。然后，单元测试可以使用ByteArrayInputStream从字节数组构造此类InputStream。该字节数组的内容在单元测试代码中可以是一个常量。

从理论上讲，这似乎是一个集成测试，因为您取决于可能更改的特定细节（文件系统）。

我会将与操作系统相关的代码抽象为它自己的模块（类，程序集，jar等）。在您的情况下，您希望加载特定的DLL（如果找到），因此创建一个IDllLoader接口和DllLoader类。您的应用程序是否已使用该接口从DllLoader获取DLL并测试了..毕竟您不对解压缩代码负责吗？

假设“文件系统交互”已在框架本身中进行了很好的测试，请创建用于流的方法并进行测试。由于框架创建者已经对FileStream.Open进行了良好的测试，因此可以将打开FileStream并将其传递给该方法的测试忽略掉。

您不应该测试类的交互和函数调用。相反，您应该考虑进行集成测试。测试所需的结果，而不是文件加载操作。

对于单元测试，我建议您在项目中包含测试文件（EAR文件或等效文件），然后在单元测试中使用相对路径，即“ ../testdata/testfile”。

只要您的项目正确导出/导入，单元测试就可以正常工作。

正如其他人所说，第一个可以作为集成测试。第二个测试仅测试功能应该实际执行的功能，而这是单元测试应执行的全部操作。

如图所示，第二个示例看起来毫无意义，但是它确实使您有机会测试函数如何响应任何步骤中的错误。在示例中，您没有进行任何错误检查，但是在实际系统中可能会存在错误检查，而依赖项注入将使您可以测试对任何错误的所有响应。那么成本将是值得的。