私有方法被公共方法使用。否则，它们就是死代码。这就是为什么要测试公共方法，断言公共方法的预期结果，从而断言它使用的私有方法。

在公共方法上运行单元测试之前，应该通过调试来测试私有方法。

也可以使用测试驱动开发来调试它们，调试单元测试，直到满足所有断言。

我个人认为最好使用TDD创建类；创建公共方法存根，然后使用预先定义的所有断言生成单元测试，这样在编写代码之前就可以确定方法的预期结果。这样，就不会走上使单元测试断言符合结果的错误道路。然后，当所有单元测试通过时，您的类是健壮的并满足要求。

首先，我要抛出一个问题：为什么你的私人成员需要隔离测试？它们是否如此复杂，提供了如此复杂的行为，以至于需要在公共表面之外进行测试？这是单元测试，而不是“代码行”测试。别为小事操心。

如果它们是那么大，足够大，以至于这些私有成员都是一个复杂度很大的“单元”，那么考虑将这些私有成员从这个类中重构出来。

如果重构不合适或不可行，在进行单元测试时，是否可以使用策略模式来替换对这些私有成员函数/成员类的访问？在单元测试中，该策略将提供额外的验证，但在发布版本中，它将是简单的传递。

测试私有方法会破坏类的封装，因为每次更改内部实现时都会破坏客户端代码（在本例中是测试）。

所以不要测试私有方法。

如果您的测试类与应该测试的类在同一个包中呢？

当然，在另一个目录中，源代码使用src&classes，测试类使用test/src和test/classes。让类和测试/类位于类路径中。

当我的类中有足够复杂的私有方法，以至于我觉得需要直接测试私有方法时，这是一种代码气味：我的类太复杂了。

我解决这些问题的通常方法是梳理出一个包含有趣内容的新类。通常，这个方法及其交互的字段，或者可以将另一个或两个方法提取到一个新类中。

新类将这些方法公开为“public”，因此可以对它们进行单元测试。新的和旧的类现在都比原来的类简单，这对我来说很好（我需要保持简单，否则我会迷路！）。

注意，我并不是建议人们不用大脑就可以创建课程！这里的重点是使用单元测试的力量来帮助您找到好的新类。

正如其他人所说。。。不要直接测试私有方法。以下是一些想法：

保持所有方法的规模和重点（易于测试，易于发现错误）使用代码覆盖工具。我喜欢Cobertura（哦，快乐的一天，它看起来像是一个新版本！）

在单元测试上运行代码覆盖率。如果您发现方法没有经过充分测试，请添加到测试中以提高覆盖率。目标是100%的代码覆盖率，但要意识到你可能无法做到这一点。