黑盒单元测试

Question

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

然而，由于单元测试必须是白盒测试(您必须模拟内部函数才能获得您想要的结果，所以您的测试需要了解代码的内部结构)，所以每当我们更改函数的实现时，我们也必须更改测试。

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

这非常耗时，而且感觉我们的工作方式是错误的。由于我们使用了所有适当的OOP指导原则(特别是封装)，所以每次更改实现时，我们不必更改其余代码，但必须更改单元测试。

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

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

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

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

因此，每次我们改变一个函数的实现(比如添加或替换一个help函数的调用)时，我们只需要改变我们的主要的大模拟。即使我们确实需要更改一些单元测试，它仍然会比以前少得多。

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

所以总而言之，有两个问题：

1. 你对黑盒单元测试的概念有什么看法？
2. 你对我们想要实现这个概念的方式有什么看法？你还有更好的主意吗？

Answer 1

您需要不同类型的测试。

did

• Integration测试(或系统测试)，它测试使用系统的实际实现及其与外部层(外部系统、数据库等)通信的能力。
• 单元测试应该是白盒测试。它应该是黑盒样式的，但每个测试都有一个特定的功能( example)
• Acceptance测试的CRUD测试应该是完全黑盒的，并由功能需求驱动(正如您的用户所说的那样)。尽可能端到端，并且不知道您选择的实现的内部情况。教科书上对黑盒测试的定义。

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

Answer 2

，因此我们几乎没有任何bug

如果你真的能够做到这一点，那么我认为你不应该做任何改变。

黑盒测试在纸面上可能听起来很吸引人，但事实是，你几乎总是需要知道被测试类的内部工作原理的一部分。现实中的provide input，verify output仅适用于简单情况。大多数时候，您的测试至少需要对测试的方法有一些了解--它如何与外部协作者交互，它调用什么方法，以什么顺序等等。

mocking和SOLID设计背后的整体思想是避免依赖实现更改导致其他类测试更改/失败的情况。相反，如果你改变了被测试方法的实现细节，那么就应该改变它测试的实现细节。这并不是什么稀奇的事。

总而言之，如果你真的能够实现几乎没有bug的，那么我会坚持这种方法。

Answer 3

tl;dr版本：

1. 黑盒单元测试是单元测试应该做的，
2. 黑盒单元测试是单元测试应该做的。正确的测试驱动开发实践就是这样做的。

完整版。

绝对不需要测试对象的私有方法。它也不会对代码覆盖率产生影响。

当您对一个类进行TDD时，您编写了检查该类行为的测试。行为是通过该类的公共方法来表达的。您永远不应该为这些方法是如何真正实现而烦恼。谷歌人对此的描述比我所能描述的要好得多：http://googletesting.blogspot.ru/2013/08/testing-on-toilet-test-behavior-not.html

如果你犯了通常的错误，静态地依赖于其他实体类，或者更糟糕的是，依赖于来自不同应用层的类，那么当你需要在测试中检查很多东西并为之准备很多东西时，你将不可避免地发现自己处于这样的境地。为了解决这个问题，依赖注入原理和Law of Demeter应运而生。