我最近遇到了这个问题，并编写了一个名为Picklock的小工具，它避免了显式使用Java反射API的问题，两个示例：

通过Java反射调用方法，例如private void方法（String s）

Method method = targetClass.getDeclaredMethod("method", String.class);
method.setAccessible(true);
return method.invoke(targetObject, "mystring");

通过Picklock调用方法，例如private void方法（String s）

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

设置字段，例如私有BigInteger金额；-通过Java反射

Field field = targetClass.getDeclaredField("amount");
field.setAccessible(true);
field.set(object, BigInteger.valueOf(42));

设置字段，例如私有BigInteger金额；-由Picklock提供

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

在尝试了Cem Catikkas使用Java反射的解决方案后，我不得不说，他的解决方案比我在这里描述的更优雅。然而，如果您正在寻找使用反射的替代方案，并且能够访问您正在测试的源代码，那么这仍然是一个选项。

测试类的私有方法可能有好处，特别是在测试驱动开发中，您希望在编写任何代码之前设计小型测试。

创建一个可以访问私有成员和方法的测试，可以测试那些只访问公共方法而难以专门针对的代码区域。如果公共方法涉及多个步骤，它可以由多个私有方法组成，然后可以单独测试。

优势：

可以测试到更精细的粒度

缺点：

测试代码必须位于文件作为源代码更难维护与.class输出文件类似，它们必须保持在源代码中声明的相同包中

然而，如果连续测试需要这种方法，这可能是一个信号，表明应该提取私有方法，可以以传统的公共方式进行测试。

下面是一个复杂的例子，说明这是如何工作的：

// Import statements and package declarations

public class ClassToTest
{
    private int decrement(int toDecrement) {
        toDecrement--;
        return toDecrement;
    }

    // Constructor and the rest of the class

    public static class StaticInnerTest extends TestCase
    {
        public StaticInnerTest(){
            super();
        }

        public void testDecrement(){
            int number = 10;
            ClassToTest toTest= new ClassToTest();
            int decremented = toTest.decrement(number);
            assertEquals(9, decremented);
        }

        public static void main(String[] args) {
            junit.textui.TestRunner.run(StaticInnerTest.class);
        }
    }
}

内部类将编译为ClassToTest$StaticInnerTest。

另请参阅：Java提示106：静态内部类以获取乐趣和利润

JML具有spec_public注释注释语法，允许您在测试期间将方法指定为public：

private /*@ spec_public @*/ int methodName(){
...
}

2.4隐私修改器和可见性中讨论了此语法。还有一个将JML规范转换为JUnit测试的程序。我不确定它的工作情况如何，或者它的功能是什么，但似乎没有必要，因为JML本身就是一个可行的测试框架。

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

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

如果你担心没有像很多帖子所建议的那样测试私有方法，那么考虑一下代码覆盖工具将准确地确定你的代码被测试了多少以及泄漏的地方，所以这样做是可以接受的。

将问题作者引向“变通方法”的答案对社区造成了巨大的伤害。测试是所有工程学科的主要组成部分。你不会想买一辆没有经过适当测试的汽车，而且测试的方式很有意义，那么为什么有人会想购买或使用测试不好的软件呢？人们这样做的原因可能是因为测试不好的软件的影响是事后才感受到的，我们通常不会把它们与身体伤害联系起来。

这是一种非常危险的观念，很难改变，但我们有责任提供安全的产品，而不管管理层如何欺负我们。想想Equifax黑客。。。

我们必须努力营造一个鼓励良好软件工程实践的环境。这并不意味着排斥我们中那些不认真对待自己手艺的弱者/懒惰者，而是创造一种责任感和自我反思的现状，鼓励每个人在精神和技能上追求成长。

我仍在学习，可能自己也有错误的看法/观点，但我坚信，我们需要对良好做法负责，避免不负责任的黑客或解决问题的方法。

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

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

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

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