问JUnit是黑盒测试还是白盒测试？

EN

在" JUnit“的名称中使用”单元“一词可能表明JUnit只适用于单元测试，而且由于单元测试实际上等同于白盒测试，因此您的怀疑是正确的。然而，事情稍微有些微妙。

单元测试，当根据这本书完成时，除了测试没有依赖项的单元之外，在所有情况下都必须是白盒测试。

在单元没有依赖关系的情况下，单元测试和集成测试之间没有区别(没有要集成的依赖关系)，因此白盒测试和黑盒测试的概念是不适用的。

对于确实有依赖关系的单元，单元测试必须是白盒测试，因为为了测试一个单元，并且只测试那个单元，您不允许将它与它的依赖项集成在一起进行测试，所以您必须剥离它的所有依赖项，并用mock替换它们，但是这样做，您声称不仅知道您的单元的依赖项是什么，更重要的是，它确切地知道它与它们交互的方式。(它调用哪些方法，使用什么参数，等等)。

然而，尽管“单元”是其名称的一部分，JUnit本身并不限制您进行单元测试，因此它既不强制使用白盒方法，也不强制使用黑盒方法。您可以使用JUnit执行您喜欢的任何类型的测试。

它添加了一个模拟框架，如JMock、Mockito等，这将使您的测试必然是白盒类型的。

当我使用JUnit时，我只做我所谓的增量集成测试。这意味着我首先测试所有没有依赖关系的单元，然后对已经测试过依赖关系的单元进行集成测试，以此类推，直到一切都测试完毕。在某些情况下，我用专门针对测试的实现替换了一些依赖项(例如，使用HSQLDB而不是实际的磁盘上的RDBMS)，但是I从不使用mock。因此，除了没有依赖项的单元的边缘情况外，I从不做单元测试，正如我已经解释过的，单元测试和集成测试之间没有区别。因此，I do白盒测试，I do黑盒测试。我使用JUnit来完成所有这些工作。(或者我自己的测试平台，它基本上与JUnit兼容。)

大多数行业似乎都在使用JUnit进行广泛的单元测试(白盒测试)和集成(黑盒)测试。

基于白盒测试定义，JUnit包含在这些形式的测试中，包含这些技术：(例如，我们基于代码创建测试，或者提供测试所有可能路径所需的所有信息。这不仅包括正确的输入，还包括不正确的输入，以便也可以验证错误处理程序。)