当我在我们的项目中越来越多地遵循我们最新的QA建议时，我感觉有必要测试私有函数:

每个函数圈复杂度不超过10。

现在，执行这项政策的副作用是，我的许多非常大的公共职能被划分为许多更集中的，更好地命名为私人职能。 公共功能仍然存在(当然)但本质上被简化为所有那些私人的“子功能”

这实际上很酷，因为调用堆栈现在更容易阅读(而不是一个大函数中的bug，我在一个子子函数中有一个bug，它具有调用堆栈中先前函数的名称，以帮助我理解“我是如何到达那里的”)

然而，现在似乎更容易直接对那些私有函数进行单元测试，而将大型公共函数的测试留给某种需要解决场景的“集成”测试。

这只是我的个人意见。

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

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

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

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

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

我不对私有方法进行单元测试。私有方法是应该对类的用户隐藏的实现细节。测试私有方法会破坏封装。

如果我发现私有方法非常庞大、复杂或重要到需要自己的测试，我就把它放在另一个类中，并在那里将它设为公共(方法对象)。然后，我可以轻松地测试以前是私有但现在是公共的方法，该方法现在存在于它自己的类中。

如果我发现私有方法非常庞大、复杂或重要到需要自己的测试，我就把它放在另一个类中，并在那里将它设为公共(方法对象)。然后，我可以轻松地测试以前私有但现在是公共的方法，它现在存在于自己的类中。