在“JUnit”名称中使用“单元”一词可能表明 JUnit 仅适用于单元测试，而且由于单元测试实际上是白盒测试的同义词，因此您的怀疑方向是正确的。然而，事情稍微微妙一些。
按照本书进行的单元测试在所有情况下都必须是白盒测试，除非测试没有依赖项的单元。
在没有依赖项的单元的情况下，单元测试和集成测试之间没有区别（没有要集成的依赖项），因此白盒与黑盒测试的概念不适用。
在单元确实有依赖关系的情况下，单元测试必然是白盒测试，因为为了测试一个单元，并且只有那个单元，你不能与它的依赖项集成来测试它，所以你必须剥离它的所有依赖，并用模拟替换它们，但这样做你不仅声称知道你的单元的依赖是什么，而且更重要的是，它以什么方式与它们交互。（它调用哪些方法，使用哪些参数等）。
然而，尽管“单元”是其名称的一部分，但 JUnit 本身并不限制您进行单元测试，因此它既不强加白盒方法，也不强加黑盒方法。您可以使用 JUnit 执行您喜欢的任何类型的测试。
添加了一个模拟框架，例如 JMock、Mockito 等，这将使您的测试必然是白盒类型的。
当我使用 JUnit 时，我只做我所谓的增量集成测试。这意味着首先我测试所有没有依赖项的单元，然后我对已经测试依赖项的单元进行集成测试，依此类推，直到所有内容都经过测试。在某些情况下，我用面向测试的特殊实现（例如，HSQLDB 而不是实际的磁盘 RDBMS）替换了一些依赖项，但我从不使用模拟。因此，除了没有依赖关系的单元的边缘情况外，我从不进行单元测试，正如我已经解释的那样，单元测试和集成测试之间没有区别。因此，我从不做白盒测试，我只做做黑盒测试。我使用 JUnit 来完成所有这些工作。（或者我自己的测试平台，它在很大程度上与 JUnit 兼容。）
大多数行业似乎都在使用 JUnit 进行广泛的单元测试（白盒测试）以及它们的集成（黑盒）测试。
小智 0
基于白盒测试定义 JUnit 包含在这些形式的测试中，包含这些技术：（例如，我们基于代码创建测试或提供测试所有可能路径所需的所有信息。这不仅包括正确的输入，还包括不正确的输入输入，以便也可以验证错误处理程序。）