在C#中，您可以使用System.Reflection，尽管在Java中我不知道。如果你“觉得你需要对私有方法进行单元测试”，我的猜测是还有其他一些地方是错误的。。。

我会认真考虑用新的眼光重新审视我的建筑。。。

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

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

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

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

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

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

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

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

如果您只使用Mockito：

您可以将私有方法视为正在测试的公共方法的一部分。您可以确保在测试公共方法时覆盖私有方法中的所有情况。

假设您是一个仅限Mockito的用户（不允许或不想使用PowerMock或反射或任何此类工具），并且不想更改正在测试的现有代码或库，这可能是最好的方法。

如果选择这种方式，唯一需要处理的就是在私有方法中本地声明的变量（用户定义的对象）。如果私有方法依赖于本地声明的变量对象及其方法，请确保将这些用户定义的对象全局声明为私有对象，而不是本地声明的对象。您可以在本地实例化这些对象。

这允许您模拟这些对象并将它们注入回测试对象。你也可以模仿（使用when/then）他们的方法。

这将允许您在测试公共方法时无错误地测试私有方法。

优势

代码覆盖范围能够测试完整的私有方法。

缺点

对象的作用域如果您不希望对象公开给同一类中的其他方法，这可能不是您的方式。当在不同的公共方法和/或在同一方法中多次调用时，您可能会多次测试私有方法。

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

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

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

我感觉完全一样。。。更改一个方法的访问修饰符，以便能够运行测试，这对我来说是个坏主意。在我们公司，我们也进行了很多讨论，在我看来，测试私有方法的好方法是使用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（）”的测试失败，那么很清楚在哪里查找错误。

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

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

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