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

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

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

我倾向于不测试私人方法。这里有疯狂。我个人认为，你应该只测试你公开的接口（包括受保护的和内部的方法）。

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);

我不确定这是否是一种好的技术，但我开发了以下模式来单元测试私有方法：

我不修改要测试的方法的可见性，也不添加其他方法。相反，我为要测试的每个私有方法添加了一个额外的公共方法。我调用这个额外的方法TestPort，并用前缀t_表示它们。然后，此测试端口方法只需访问相应的私有方法。

此外，我向测试端口方法添加了一个布尔标志，以决定是否从外部通过测试端口方法授予对私有方法的访问权。然后在静态类中全局设置该标志，在该类中我放置了例如应用程序的其他全局设置。因此，我可以在一个地方打开和关闭对私有方法的访问，例如，在相应的单元测试中。

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

在过去，我曾为Java使用过反射，在我看来这是一个很大的错误。

严格来说，您不应该编写直接测试私有方法的单元测试。您应该测试的是类与其他对象的公共契约；您不应该直接测试对象的内部。如果另一个开发人员想要对类进行一个小的内部更改，这不会影响类的公共契约，那么他/她就必须修改基于反射的测试，以确保它正常工作。如果在整个项目中重复这样做，那么单元测试就不再是代码健康状况的有用度量，而开始成为开发的障碍，成为开发团队的烦恼。

相反，我建议使用一个代码覆盖工具，例如Cobertura，以确保您编写的单元测试在私有方法中提供代码的适当覆盖。通过这种方式，您可以间接测试私有方法正在做什么，并保持更高级别的灵活性。