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

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

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

PowerMockito就是为此而生的。

使用Maven依赖项：

    <dependency>
        <groupId>org.powermock</groupId>
        <artifactId>powermock-core</artifactId>
        <version>2.0.7</version>
        <scope>test</scope>
    </dependency>

那你就可以了

import org.powermock.reflect.Whitebox;
...
MyClass sut = new MyClass();
SomeType rval = Whitebox.invokeMethod(sut, "myPrivateMethod", params, moreParams);

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

一般来说，单元测试旨在使用类或单元的公共接口。因此，私有方法是您不希望显式测试的实现细节。

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

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

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

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

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

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

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

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