如果方法足够重要/复杂，我通常会让它“受保护”并测试它。一些方法将保持私有，并作为公共/受保护方法的单元测试的一部分进行隐式测试。

我们通过推断来测试私有方法，我的意思是我们寻找总类测试覆盖率至少为95%，但我们的测试只调用公共方法或内部方法。为了获得覆盖，我们需要根据可能发生的不同场景对公众/内部人员进行多次调用。这使得我们的测试更专注于它们所测试的代码的目的。

特朗皮对你链接的帖子的回答是最好的。

我从来不理解单元测试的概念，但现在我知道它的目标是什么了。

单元测试不是一个完整的测试。所以，它并不是QA和手动测试的替代品。在这方面，TDD的概念是错误的，因为你不能测试所有的东西，包括私有方法，也包括使用资源的方法(特别是我们无法控制的资源)。TDD的所有质量都是无法实现的。

单元测试更像是一个枢轴测试，你标记一些任意的枢轴，枢轴的结果应该保持不变。

如果私有方法定义良好(即，它有一个可测试的函数，并且不会随着时间的推移而改变)，那么是的。我在有意义的地方测试所有可测试的东西。

例如，加密库可能会隐藏这样一个事实，即它使用一次仅加密8个字节的私有方法执行块加密。我会为此写一个单元测试——它并不意味着要改变，即使它是隐藏的，如果它真的坏了(例如，由于未来的性能增强)，那么我想知道是私有函数坏了，而不仅仅是某个公共函数坏了。

它加快了以后的调试。

亚当

其中一个要点是

如果我们测试以确保逻辑的正确性，并且私有方法携带逻辑，那么我们应该测试它。不是吗?我们为什么要跳过这个呢?

基于方法的可见性编写测试是完全无关的想法。

相反

另一方面，在原始类之外调用私有方法是一个主要问题。在一些模拟工具中，模拟私有方法也有局限性。(例:5)

虽然有一些工具如Power Mock支持这一点，但这是一个危险的操作。原因是它需要破解JVM来实现这一点。

一种可以解决的方法是(如果您想为私有方法编写测试用例)

将这些私有方法声明为受保护的。但在某些情况下可能不方便。

不，你不应该测试私有方法，为什么?此外，流行的mock框架(如Mockito)不支持测试私有方法。