使用哪种方法对这个组件进行单元测试？善于交际还是孤独？

Question

我需要实现将 Zip 子文件夹提取到文件夹中的功能。候选接口可能是（Java）：

interface ZipExtractor {
    void extract(File zipFile, String subfolderName, File targetFolder);
}

当我打算实现这个接口时，我将有两个相关的子组件：一个能够列出 zip 子文件夹中的文件的类，以及一个可以从 zip 中提取单个文件的类。

我在谷歌上搜索了很多关于这个案例的最佳实践，并发现了一些有趣的争论，例如：

• 独立单元测试与社交单元测试
• mockist vs 经典风格
• “应始终模拟文件系统访问”与“没关系，但测试套件运行时间没有太大影响”

什么是最好的选择：

• 按原样使用 ZipExtractor，为其提供文件系统上存在的真实文件，并检查文件是否已正确提取？这听起来更像是一个小型集成测试，但代码更小更简单，我测试了整个功能。
• 模拟 ZipExtractor 的子组件以返回一个虚假的子文件列表，而不是写入文件系统，并在子组件上添加测试？这是真正的单元测试，但需要从测试中进行更多配置，因此代码更加冗长。

我个人的感觉是使用第一种方法，但我想要其他带有论据的意见。谢谢

Answer 1

在这里，单一测试意味着断言一系列方法调用。
你会模拟很多东西，最后你将无法为用例检查一个真正有用的东西。您将主要检查是否调用了方法。 .

这有点像断言执行了一个 SQL 查询。
这是无助的。我们在这里想要检查查询的结果或模拟执行查询的服务。
你永远不会模拟连接、查询、语句等......

当有一些逻辑要测试时，单一测试具有很大的价值：计算、转换等...
当您将文件夹从 zip 解压缩到目标文件夹时，这里会发挥巨大的价值。
所以和你一样，我更喜欢第一种方式：

按原样使用 ZipExtractor，给它一个存在于文件中的真实文件 系统，并检查文件是否正确提取？听起来更 就像一个小型集成测试，但代码更小更简单，我 测试整个功能。

最后，必须维护测试，而创建没有附加价值的测试通常是一种罪过，因为这些测试通常没有维护或维护得不好。

Answer 2

问题是您喜欢“对组件进行单元测试”的说法，但并不真正喜欢对组件进行单元测试的想法。因此，您希望有人祝福您进行集成测试，但仍称其为“单元测试”。

这就像问是否可以用真正的肉制作素食汉堡，因为它的味道要好得多。但仍然坚持称它为“素食汉堡”，因为它听起来更好。

底线：继续使用真正的文件系统。只是不要称它为单元测试。除非你真的喜欢它的声音并且你的同事同意，否则你可以称它为“应用程序服务器”或“猫”或“牙刷”。

Answer 3

按原样使用 ZipExtractor，给它一个存在于文件系统上的真实文件，并检查文件是否正确提取

这很好。被测单元，即您想要证明工作正常的东西，是从 zip 存档中提取子文件夹。因此，在这种情况下，您成功地测试了从存档中提取的单元，尽管依赖于其他单元。

当然，这意味着另一个单元中的错误可能导致此测试失败，尽管您要测试的单元正常工作。为确保在发生故障时能够识别真正的问题域，对列出存档中文件的类进行额外测试可能也是一个好主意。

...听起来更像是一个小型集成测试，但代码更小更简单，我测试了整个功能。

对此有不同的思想流派。 Martin Fowler，writes this 关于这个主题（我自己强调）：

确实，使用社交单元测试是我们因使用“单元测试”一词而受到批评的原因之一。我认为“单元测试”这个词是合适的，因为这些测试是对单个单元行为的测试。 我们假设除该单元以外的所有内容都正常工作。

然而，在更复杂的情况下，模拟可能更适合文件系统等外部资源。我觉得应该逐案考虑。对此，Martin Fowler 写道

如果与资源的对话对您来说足够稳定且足够快，那么在您的单元测试中没有理由不这样做。

在这种情况下，确保您的 zip 文件存在、具有正确的权限等应该是相当稳定的。所以，我说你没有理由不能在你的单元测试中使用 zipfile 和文件系统。

不过，听起来您可能已经阅读过这些讨论。正如你可能已经确定的那样，这真的取决于你问的是谁。我对以您描述的方式编写测试的最大恐惧不是代码是否经过正确测试，而是有人会用他们的规则书打败我，因为他们对单元测试的想法与我的不同。