私有方法由公共方法调用，因此公共方法的输入也应测试这些公共方法调用的私有方法。当公共方法失败时，这可能是私有方法的失败。

私有方法由公共方法调用，因此公共方法的输入也应测试这些公共方法调用的私有方法。当公共方法失败时，这可能是私有方法的失败。

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

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

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

对于Java，我会使用反射，因为我不喜欢仅仅为了测试而更改对声明方法的包的访问。然而，我通常只测试公共方法，这也应该确保私有方法正常工作。

不能使用反射从所有者类外部获取私有方法，私有修饰符也会影响反射

这不是真的。你当然可以，正如塞姆·卡提卡斯的回答中所提到的。

我想测试私有方法的两个例子：

解密例程-我不会想让任何人都能看到它们为了测试，否则任何人都可以使用它们来解密。但他们是代码固有的、复杂的，并且需要始终工作（明显的例外是反射，在大多数情况下，当SecurityManager未配置为防止这种情况发生时，反射甚至可以用于查看私有方法）。为社区创建SDK消耗在这里，公众对完全不同的含义，因为是全世界都能看到的代码（不仅仅是我的应用程序内部）。我把如果我不这样做，请将代码转换为私有方法希望SDK用户看到它-我不要将其视为代码气味SDK编程是如何工作的。但是当然我还需要测试私有方法，它们在哪里我的SDK的功能生活。

我理解只测试“合同”的想法。但我看不出有人可以主张不测试代码，因为您的里程可能会有所不同。

因此，我的权衡涉及到用反射使JUnit测试复杂化，而不是损害我的安全性和SDK。

正如上面许多人所建议的，一个好的方法是通过公共接口测试它们。

如果您这样做，最好使用代码覆盖工具（如EMMA）来查看您的私有方法是否确实在测试中执行。