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

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

它加快了以后的调试。

亚当

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

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

其中一个要点是

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

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

相反

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

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

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

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

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

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

你也可以让你的方法包私有，即默认，你应该能够单元测试它，除非它被要求是私有的。

I understand the point of view where private methods are considered as implementations details and then don't have to be tested. And I would stick with this rule if we had to develop outside of the object only. But us, are we some kind of restricted developers who are developing only outside of objects, calling only their public methods? Or are we actually also developing that object? As we are not bound to program outside objects, we will probably have to call those private methods into new public ones we are developing. Wouldn't it be great to know that the private method resist against all odds?

我知道有些人会回答说，如果我们正在开发另一个公共方法到那个对象中，那么这个方法应该被测试，就是这样(私有方法可以在没有测试的情况下继续存在)。但这也适用于一个对象的任何公共方法:当开发一个web应用程序时，一个对象的所有公共方法都是从控制器方法调用的，因此可以认为是控制器的实现细节。

那么为什么我们要单元测试对象呢?因为这是非常困难的，不是说不可能，以确保我们正在测试控制器的方法与适当的输入将触发底层代码的所有分支。换句话说，我们在堆栈中的位置越高，测试所有行为就越困难。私有方法也是如此。

对我来说，私人方法和公共方法之间的界限是测试时的心理标准。对我来说更重要的标准是:

该方法是否在不同的地方被多次调用? 这种方法是否复杂到需要测试?