unit-testing - 黑盒单元测试

Question

在我的上一个项目中，我们进行了几乎 100% cc 的单元测试，因此我们几乎没有任何错误。

但是，由于单元测试必须是白盒(您必须模拟内部函数才能获得所需的结果，因此您的测试需要了解代码的内部结构)任何时候我们更改函数的实现，我们都必须也改变测试。

请注意，我们没有更改函数的逻辑，只是更改了实现。

这非常耗时，感觉好像我们的工作方式不对。
由于我们使用了所有正确的 OOP 指南(特别是封装)，所以每次我们更改实现时，我们不必更改其余代码，但必须更改单元测试。

感觉好像我们是在为测试服务，而不是他们为我们服务。

为了防止这种情况，我们中的一些人认为单元测试应该是黑盒测试。

如果我们为整个域创建一个大模拟，并在一个地方为每个类中的每个函数创建一个 stub ，并在每个单元测试中使用它，那将是可能的。

当然，如果一个特定的测试需要调用特定的内部函数(比如确保我们写入数据库)，我们可以覆盖我们的 stub 。

因此，每次我们更改函数的实现(例如添加或替换对帮助函数的调用)时，我们只需要更改我们的 main big mock。即使我们确实需要更改一些单元测试，它仍然会比以前少得多。

其他人认为单元测试必须是白盒测试，因为您不仅要确保您的应用程序在特定位置写入数据库，还要确保您的应用程序不会在其他任何地方写入数据库，除非您特别期望它到。虽然这是一个有效的观点，但我认为不值得花时间编写白盒测试而不是黑盒测试。

所以总结一下，有两个问题:

您如何看待黑盒单元测试的概念？

您如何看待我们想要实现该概念的方式？你有更好的想法吗？

Answer 1

您需要不同类型的测试。

应该是白盒测试的单元测试，就像你所做的

集成测试(或系统测试)，测试使用系统实际实现的能力及其与外部层(外部系统、数据库等)的通信，应该是黑盒样式的，但每个都针对特定的功能(例如 CRUD 测试)

验收测试应该是完全黑盒的，并且由功能需求驱动(正如您的用户所说的那样)。尽可能端到端，并且不知道您选择的实现的内部。黑盒测试的教科书定义。

请记住，在大多数情况下，代码覆盖率是没有意义的。您需要高行覆盖率(或方法覆盖率，无论您的计数方法是什么)，但这通常是不够的。你需要思考的概念是 功能覆盖 :确保涵盖了您的所有要求和逻辑路径。