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

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

对于从测试中调用什么api，公共和私有并不是一个有用的区分，方法和类也不是。大多数可测试单元在一个上下文中是可见的，但在其他上下文中是隐藏的。

重要的是覆盖范围和成本。您需要最小化成本，同时实现项目的覆盖目标(行、分支、路径、块、方法、类、等价类、用例……)不管团队怎么决定)。

因此，使用工具来确保覆盖率，并设计您的测试以减少成本(短期和长期)。

不要让测试变得过于昂贵。 如果只测试公共入口是最便宜的，那就这样做。 如果测试私有方法成本最低，那就这么做。

随着您的经验越来越丰富，您将能够更好地预测何时值得重构以避免测试维护的长期成本。

绝对是的。这就是单元测试的要点，你测试单元。私有方法是一个单元。没有测试私有方法，TDD(测试驱动开发)是不可能的，

其中一个要点是

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

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

相反

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

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

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

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

如果您不测试您的私有方法，您怎么知道它们不会崩溃呢?

我认为最好只测试对象的公共接口。从外部世界的角度来看，只有公共接口的行为是重要的，这是您的单元测试应该指向的方向。

一旦你为一个对象编写了一些可靠的单元测试，你就不希望因为接口背后的实现改变了而不得不回去修改那些测试。在这种情况下，您已经破坏了单元测试的一致性。