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

您可以创建一个特殊的公共方法来代理要测试的私有方法。使用IntelliJ时，@TestOnly注释是现成的。缺点是，如果有人想在公共环境中使用私有方法，他可以这样做。但注释和方法名会警告他。在IntelliJ上，执行此操作时将显示警告。

import org.jetbrains.annotations.TestOnly

class MyClass {

    private void aPrivateMethod() {}

    @TestOnly
    public void aPrivateMethodForTest() {
        aPrivateMethod()
    }
}

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

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

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

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

所以不要测试私有方法。

我使用的另一种方法是将私有方法更改为打包私有或受保护的方法，然后使用GoogleGuava库的@VisibleForTesting注释对其进行补充。

这将告诉使用此方法的任何人要小心，即使在包中也不要直接访问它。同样，测试类不需要在物理上位于同一个包中，而是位于测试文件夹下的同一包中。

例如，如果要测试的方法位于src/main/java/mybackage/MyClass.java中，那么您的测试调用应该位于src/test/java/mypackage/MiClassTest.java中。这样，您就可以访问测试类中的测试方法。

JUnit.org常见问题解答页面的答案：

但如果你必须。。。如果您使用的是JDK1.3或更高版本，则可以使用反射来颠覆访问控制机制。有关如何使用它的详细信息，请阅读本文。如果您使用的是JDK1.6或更高版本，并且使用@测试时，可以使用Dp4j在测试方法中注入反射。对于有关如何使用它的详细信息，请参阅此测试脚本。

P.S.我是Dp4j的主要贡献者。问我你是否需要帮助。：）