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

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

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

我认为大多数答案都太粗糙了。这取决于您的代码是否应该测试私有方法。

我过去使用了私人方法测试，我是通过反思来完成的。它对我有用。我意识到它的问题，但对我来说，这是最好的解决方案。

我有一个强大的应用程序，可以模拟100多万人口中的人类行为。每个人都由一个对象表示。该应用程序的主要目的是跟踪某些东西（疾病、信息、思想）如何在人群中传播。

为此，我有方法将疾病或信息从一个对象传递给另一个对象。绝对没有理由公开这些方法，因为最终用户对人与人之间的一次传递不感兴趣。最终用户只对它如何在人群中传播的全貌感兴趣。所以这些方法是私人的。

但我想肯定的是，从一个人向另一个人传递一点信息的行为是否在做它应该做的事情。通过公共用户界面测试它也是不可能的，因为它只是不公开，我认为仅仅为了测试而公开它是很尴尬的。应用程序的最终输出由一直执行的数亿个这样的单个步骤定义。我也不能测试最终输出，因为这涉及到复杂的随机性，这使得它无法预测。

因此，我测试应用程序的方法是测试从一个人向另一个人传递信息的单个步骤。这些都是私人方法。所以我用反思来检验这一点。

我讲这个故事是为了表明这不是一个简单的黑白故事。这取决于您的应用程序。在某些情况下，通过反射测试私有方法可能是最好的选择。

如果这里的一些人在我的用例中知道更好的解决方案，我当然乐意接受纠正。。。。

当我的类中有足够复杂的私有方法，以至于我觉得需要直接测试私有方法时，这是一种代码气味：我的类太复杂了。

我解决这些问题的通常方法是梳理出一个包含有趣内容的新类。通常，这个方法及其交互的字段，或者可以将另一个或两个方法提取到一个新类中。

新类将这些方法公开为“public”，因此可以对它们进行单元测试。新的和旧的类现在都比原来的类简单，这对我来说很好（我需要保持简单，否则我会迷路！）。

注意，我并不是建议人们不用大脑就可以创建课程！这里的重点是使用单元测试的力量来帮助您找到好的新类。

这是我的龙目样本：

public static void main(String[] args) throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException, NoSuchMethodException, InvocationTargetException {
    Student student = new Student();

    Field privateFieldName = Student.class.getDeclaredField("name");
    privateFieldName.setAccessible(true);
    privateFieldName.set(student, "Naruto");

    Field privateFieldAge = Student.class.getDeclaredField("age");
    privateFieldAge.setAccessible(true);
    privateFieldAge.set(student, "28");

    System.out.println(student.toString());

    Method privateMethodGetInfo = Student.class.getDeclaredMethod("getInfo", String.class, String.class);
    privateMethodGetInfo.setAccessible(true);
    System.out.println(privateMethodGetInfo.invoke(student, "Sasuke", "29"));
}


@Setter
@Getter
@ToString
class Student {
    private String name;
    private String age;
    
    private String getInfo(String name, String age) {
        return name + "-" + age;
    }
}

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

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

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

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

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

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