如果你的私有方法没有通过调用公共方法来测试，那么它在做什么? 我说的是私人的，不是受保护的，也不是朋友。

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

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

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

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

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

这只是我的个人意见。

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

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

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

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

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

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

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

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

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

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

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

我从来不理解单元测试的概念，但现在我知道它的目标是什么了。

单元测试不是一个完整的测试。所以，它并不是QA和手动测试的替代品。在这方面，TDD的概念是错误的，因为你不能测试所有的东西，包括私有方法，也包括使用资源的方法(特别是我们无法控制的资源)。TDD的所有质量都是无法实现的。

单元测试更像是一个枢轴测试，你标记一些任意的枢轴，枢轴的结果应该保持不变。