如果方法足够重要/复杂，我通常会让它“受保护”并测试它。一些方法将保持私有，并作为公共/受保护方法的单元测试的一部分进行隐式测试。

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

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

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

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

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

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

如果您不测试您的私有方法，您怎么知道它们不会崩溃呢?

测试的目的是什么?

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

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

考虑:您有一个公共方法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.