从测试框架测试Java私有方法的最佳合法方法是在方法上添加@VisibleForTesting注释，因此相同的方法将像公共方法一样在测试框架中可见。

我感觉完全一样。。。更改一个方法的访问修饰符，以便能够运行测试，这对我来说是个坏主意。在我们公司，我们也进行了很多讨论，在我看来，测试私有方法的好方法是使用Java反射或其他框架，使方法可测试。对于复杂的私有方法，我多次这样做，这有助于保持测试的小型性、可读性和可维护性。

在我阅读了这里的所有答案之后，我只是不同意那些说“如果你需要测试私有方法，那么会有代码气味”或甚至“不要测试私有方法”的人。。。所以我给你举个小例子：

假设我有一个带有一个公共方法和两个私有方法的类：

public class ConwaysGameOfLife {

    private boolean[][] generationData = new boolean[128][128];

    /**
     * Compute the next generation and return the new state
     * Also saving the new state in generationData
     */
    public boolean[][] computeNextGeneration() {
        boolean[][] tempData = new boolean[128][128];

        for (int yPos=0; yPos<=generationData.length; yPos++) {
            for (int xPos=0; xPos<=generationData[yPos].length; xPos++) {
                int neighbors = countNeighbors(yPos, xPos);
                tempData[yPos][xPos] = determineCellState(neighbors, yPos, xPos);
            }
        }

        generationData = tempData;
        return generationData;
    }

    /**
     * Counting the neighbors for a cell on given position considering all the edge cases
     *
     * @return the amount of found neighbors for a cell
     */
    private int countNeighbors(int yPos, int xPos) {}

    /**
     * Determine the cell state depending on the amount of neighbors of a cell and on a current state of the cell
     *
     * @return the new cell state
     */
    private boolean determineCellState(int neighborsAmount, int yPos, int xPos) {}
}

因此，至少对于“countNeighbors”方法，我需要测试八个边缘情况和一些一般情况（直接位于角落的单元格、直接位于矩阵边缘的单元格和位于中间的单元格）。因此，如果我只是试图通过“computeNextGeneration”方法覆盖所有的情况，并且在重构之后，一些测试是红色的，那么识别错误所在的位置可能需要花费时间。

如果我分别测试“determineCellState”和“countNeighbors”，并且在重构和优化之后，“computeNextGeneration”和“determine CellState”的测试是红色的，那么我很确定错误将出现在“determiseCellState”方法中。

此外，如果您从一开始就为这些方法编写单元测试，这些测试将帮助您开发方法/算法，而无需考虑和包装公共方法中的其他方法调用和案例。你只需要在方法中编写快速的小测试来覆盖你的案例。。。例如，如果名为“countNeighbors_should_return_right_amount_of_noughbors_for_the_right_top_corner_cell（）”的测试失败，那么很清楚在哪里查找错误。

如果您确实需要直接测试私有方法/类等，那么可以使用其他答案中已经提到的反射。然而，如果说到这一点，我宁愿使用框架提供的实用程序类，而不是直接处理反射。例如，对于Java，我们有：

Spring框架中的ReflectionUtilsJUnit中的ReflectionUtils

关于如何使用它们，你可以在网上找到很多文章。我特别喜欢这个：

org.springframework.util.ReflectionUtils的Java代码示例

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

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

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

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

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

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

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

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

从本文：使用JUnit和SuiteRunner测试私有方法（Bill Venners）中，您基本上有4个选项：

不要测试私有方法。授予方法包访问权限。使用嵌套测试类。使用反射。

在尝试了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：静态内部类以获取乐趣和利润