我看到很多人都有同样的想法:在公共层面上进行测试。但这不正是我们的QA团队所做的吗?他们测试输入和预期输出。如果作为开发人员，我们只测试公共方法，那么我们只是在重做QA的工作，而不是通过“单元测试”来增加任何价值。

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

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

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

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

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

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

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应用程序时，一个对象的所有公共方法都是从控制器方法调用的，因此可以认为是控制器的实现细节。

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

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

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

测试的目的是什么?

到目前为止，大多数答案都说私有方法是实现细节，只要公共接口经过良好测试并能够正常工作，这些实现细节就不重要(至少不应该)。如果测试的唯一目的是保证公共接口正常工作，那么这是绝对正确的。

就我个人而言，我对代码测试的主要用途是确保将来的代码更改不会导致问题，并且在出现问题时帮助我进行调试。我发现对私有方法的测试就像对公共接口的测试一样彻底(如果不是更彻底的话!)，可以进一步达到这个目的。

考虑:您有一个公共方法A，它调用私有方法B。A和B都使用方法C。C被更改(可能由您更改，也可能由供应商更改)，导致A开始测试失败。对B进行测试不是很有用吗，即使它是私有的，这样你就知道问题是在A使用C, B使用C，还是两者都有?

Testing private methods also adds value in cases where test coverage of the public interface is incomplete. While this is a situation we generally want to avoid, the efficiency unit testing depends both on the tests finding bugs and the associated development and maintenance costs of those tests. In some cases, the benefits of 100% test coverage may be judged insufficient to warrant the costs of those tests, producing gaps in the public interface's test coverage. In such cases, a well-targeted test of a private method can be a very effective addition to the code base.

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

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

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

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

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

这只是我的个人意见。