我已经阅读了这篇关于如何测试私有方法的文章。我通常不测试它们，因为我总是认为只测试将从对象外部调用的公共方法更快。你测试私有方法吗?我应该一直测试它们吗?
当前回答
我不对私有方法进行单元测试。私有方法是应该对类的用户隐藏的实现细节。测试私有方法会破坏封装。
如果我发现私有方法非常庞大、复杂或重要到需要自己的测试，我就把它放在另一个类中，并在那里将它设为公共(方法对象)。然后，我可以轻松地测试以前是私有但现在是公共的方法，该方法现在存在于它自己的类中。
其他回答
其中一个要点是
如果我们测试以确保逻辑的正确性，并且私有方法携带逻辑，那么我们应该测试它。不是吗?我们为什么要跳过这个呢?
基于方法的可见性编写测试是完全无关的想法。
相反
另一方面，在原始类之外调用私有方法是一个主要问题。在一些模拟工具中，模拟私有方法也有局限性。(例:5)
虽然有一些工具如Power Mock支持这一点，但这是一个危险的操作。原因是它需要破解JVM来实现这一点。
一种可以解决的方法是(如果您想为私有方法编写测试用例)
将这些私有方法声明为受保护的。但在某些情况下可能不方便。
你也可以让你的方法包私有，即默认，你应该能够单元测试它，除非它被要求是私有的。
当我在我们的项目中越来越多地遵循我们最新的QA建议时，我感觉有必要测试私有函数:
每个函数圈复杂度不超过10。
现在，执行这项政策的副作用是，我的许多非常大的公共职能被划分为许多更集中的，更好地命名为私人职能。 公共功能仍然存在(当然)但本质上被简化为所有那些私人的“子功能”
这实际上很酷，因为调用堆栈现在更容易阅读(而不是一个大函数中的bug，我在一个子子函数中有一个bug，它具有调用堆栈中先前函数的名称，以帮助我理解“我是如何到达那里的”)
然而，现在似乎更容易直接对那些私有函数进行单元测试，而将大型公共函数的测试留给某种需要解决场景的“集成”测试。
这只是我的个人意见。
我认为单元测试是用来测试公共方法的。您的公共方法使用您的私有方法，因此它们也间接地接受测试。
如果您不测试您的私有方法，您怎么知道它们不会崩溃呢?
