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

你不应该这么做。如果您的私有方法有足够的复杂性，必须进行测试，您应该将它们放在另一个类中。保持高内聚性，类应该只有一个目的。类公共接口应该足够了。

正如上面引用的，“如果你不测试你的私有方法，你怎么知道它们不会崩溃?”

这是一个大问题。单元测试的一个重要要点是尽快知道在哪里、何时以及如何发生故障。这样就减少了大量的开发和QA工作。如果所有测试的都是公开的，那么您就没有对类的内部进行诚实的覆盖和描述。

我发现最好的方法之一是将测试引用添加到项目中，并将测试放在与私有方法并行的类中。放入适当的构建逻辑，这样测试就不会构建到最终项目中。

然后，您就有了测试这些方法的所有好处，您可以在几秒钟内而不是几分钟或几小时内发现问题。

总之，单元测试你的私有方法。

我认为单元测试是用来测试公共方法的。您的公共方法使用您的私有方法，因此它们也间接地接受测试。

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

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

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

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

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

这只是我的个人意见。

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

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