单元测试中的文件访问是否错误？

Question

在编写处理XML的单元测试时（例如测试读取/生成XML的类）我曾经在单元测试旁边的单独文件中编写断言结果XML-String / my input XML String。假设我有一个“MyTransformer”类，它将一种XML格式转换为另一种XML格式。然后我会在同一个包中创建三个文件：

• MyTransformerTest.java
• MyTransformerTestSampleInput.xml
• MyTransformerTestExpectedOutput.xml

然后我的断言可能看起来像这样（为简单起见，简化了伪代码）：

Reader transformed = MyTransformer.transform(getResourceAsStream("MyTransformerTestSampleInput.xml")));
Reader expected = getResourceAsStream("MyTransformerTestExpectedOutput.xml");
assertXMLEqual(expected, transformed);

然而，一位同事告诉我，我在本单元测试中访问的文件是不可接受的。他建议创建一个包含我的XML文件内容的文字字符串常量（私有静态最终字符串），可能在一个单独的groovy类中，因为多行字符串的好处而不是将XML文件写入文件。

我不喜欢文字字符串常量的想法，因为即使我在groovy中有多行字符串，我仍然会松开语法高亮显示以及我的XML编辑器的所有其他有用功能，它们会立即告诉我我的XML是否存在语法错误等

你怎么看？文件访问真的很糟糕吗？如果是这样：为什么？如果不是为什么可以呢？

Answer 1

单元测试中的文件存在两个问题：

• 它们会减慢测试周期。您可能需要进行数千次单元测试，最好是在每次构建时运行 - 所以它们应该尽可能快。如果你可以加速它们（例如，通过摆脱I / O操作）你想要这样做。当然它并不总是可行的，所以你通常通过NUnit [Category]或类似的东西来分离“慢”测试 - 然后不那么频繁地运行那些特殊的测试 - 比如，只在Nightly版本上。
• 他们引入了其他依赖项。如果测试需要一个文件，它不仅会在测试背后的逻辑错误时失败，而且当文件丢失或者测试运行器没有读取权限等时也会失败。这使得调试和修复不那么令人满意！ / LI>

那就是说，在测试中不使用文件我不会太严格。如果可能的话，尽量避免它们，但不要生气。确保您考虑可维护性与速度 - 测试越干净，以后就越容易修复和理解它。

Answer 2

如果您的单元测试访问文件以将假测试数据提供给被测系统，那么您可以运行测试，这不是问题。这实际上有助于您在被测系统中使用更多种类的测试数据。

但是，如果您的系统测试访问文件系统，则从测试执行时，这不是单元测试。这是一个集成测试。这是因为您正在访问诸如文件系统之类的横切问题，并且它们无法归类为单元测试。

使用单元测试，您将真正隔离/伪造文件访问权限并测试代码的行为（如果有）。它们更快，更容易运行。如果写得正确，它会给你一个引脚点反馈。

Answer 3

在这些情况下，我有一个单元测试，它使用文件的内部表示，在这种情况下是一个字符串文字。

我还将进行集成测试，以便在写入文件时测试代码是否正常工作。

所以这完全取决于单元/集成测试定义。两者都是有效的测试，只取决于你当时正在编写的测试。

Answer 4

如果xml更具可读性，或者更容易在文件中使用xml，并且您有很多这样的测试，我将保留它们。

严格来说，单元测试不应使用文件系统，因为它很慢。但是，可读性更为重要。文件中的XML更易于阅读，并且可以在XML友好的编辑器中加载。

如果测试需要很长时间才能运行（因为其中有很多），或者您的同事抱怨，请将其移至集成测试。

如果您在Windows和LINUX上工作，则必须注意构建服务器会拾取文件。

没有完美的答案。