java - 使用哪种方法来对该组件进行单元测试？善于交际还是独来独往？

Question

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

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

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

我在谷歌上搜索了很多关于这种情况的最佳实践，并发现了一些有趣的辩论，例如:

• 单独与社交单元测试
• 模仿风格与经典风格
• “文件系统访问应该始终被模拟”与“没关系，但测试套件运行时间不会受到太大影响”

最好的选择是什么:

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

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

Answer 1

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

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

当需要测试一些逻辑时，单一测试具有很大的值(value):计算、转换等......
当您将 zip 中的文件夹提取到目标文件夹时，就会发挥巨大的作用。
所以像你一样我更喜欢第一种方式:

using ZipExtractor as is, give it a real file existing on the file system, and check that files are correctly extracted ? It sounds more like a mini-integration test but the code is smaller and simpler and I test the whole feature.

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