4

在编写处理 XML 的单元测试时（例如测试读取/生成 XML 的类），我曾​​经将我的断言结果 XML-String / 我的输入 XML 字符串写入单元测试旁边的单独文件中。假设我有一个类“MyTransformer”，可以将一种 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 是否有语法错误等。

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

4

4 回答 4

5

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

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

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

于 2013-06-18T11:15:23.153 回答
0

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

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

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

于 2013-06-18T19:22:05.180 回答
0

如果您的单元测试访问文件以将伪造的测试数据提供给被测系统，那么您可以运行测试，那不是问题。这实际上可以帮助您在被测系统中使用更广泛的测试数据。

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

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

于 2013-06-18T13:49:12.540 回答
0

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

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

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

如果您在 Windows 和 LINUX 中工作，则必须小心文件被构建服务器拾取。

没有完美的答案。

于 2019-03-05T19:25:39.357 回答