Question

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

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

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

我在这个案例中搜索了很多最佳做法，并发现了一些有趣的辩论，如：

最佳选择是什么：

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

我个人的感觉是使用第一种方法，但我希望其他观点有争议。感谢

Answer 1

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

这有点像断言执行SQL查询这是无助的。我们在这里想要的是检查查询的结果或模拟执行查询的服务你永远不会模仿连接，查询，声明等......

当有一些逻辑需要测试时，单一测试具有很大的价值：计算，转换等...... 将zip文件夹中的文件夹解压缩到目标文件夹时，执行此值很大所以和你一样，我更喜欢第一种方式：

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

最后，必须保持测试并且创建没有附加值的测试通常是一种罪恶，因为这些测试通常不会被维护或保持不良。

Answer 2

问题是你喜欢“单元测试组件”的声音，但不喜欢单元测试组件的想法。所以你希望有人给你一个进行集成测试的祝福，但仍称它为“单元测试”。

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

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

Answer 3

按原样使用ZipExtractor，为其提供文件系统中存在的真实文件，并检查文件是否已正确提取

这很好。您要证明的东西可以正常工作，就是要测试的单元是从zip存档中提取子文件夹。因此，在这种情况下，即使依赖其他单位，您也可以成功测试从存档中提取的单位。

自然，这意味着即使您要测试的单元正常运行，另一个单元中的错误也可能导致该测试失败。为了确保您能够在发生故障的情况下识别出真正的问题域，对列出存档中文件的类进行额外的测试也可能是一个好主意。

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

对此有不同的思想流派。马丁·福勒（Martin Fowler），writes this关于这个问题（我自己强调了）：

事实上，使用社交化的单元测试是我们使用“单元测试”一词而受到批评的原因之一。我认为术语“单元测试”是适当的，因为这些测试是对单个单元行为的测试。 我们假设该单元以外的所有其他功能都正常运行，则编写测试。

但是，在更复杂的情况下，模拟可能更适合文件系统等外部资源。我认为应该逐案考虑。马丁·福勒（Martin Fowler）在此写道

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

在这种情况下，确保您的zip文件存在，具有正确的权限等应该非常稳定。因此，我说没有理由不应该将zipfile和文件系统用作单元测试的一部分。

不过，听起来您可能已经阅读了这些讨论。您可能已经确定，这实际上取决于您问的是谁。我对以您描述的方式编写测试的最大担心不是代码是否经过正确测试，而是有人会用规则书击败我，因为他们对单元测试的想法与我的不同。 / p>