如果您试图测试您不愿意或无法更改的现有代码，则反射是一个不错的选择。

如果类的设计仍然是灵活的，并且您有一个复杂的私有方法需要单独测试，我建议您将其导出到一个单独的类中，并单独测试该类。这不需要更改原始类的公共接口；它可以在内部创建helper类的实例并调用helper方法。

如果您想测试来自helper方法的困难错误条件，可以更进一步。从helper类中提取一个接口，向原始类中添加一个公共getter和setter以注入helper类（通过其接口使用），然后将helper类的模拟版本注入原始类中，以测试原始类如何响应helper的异常。如果您想测试原始类而不同时测试助手类，这种方法也很有用。

Android具有Android.support.annotation包中的@VisibleForTesting注释。

@VisibleForTesting注释表明，一个带注释的方法比通常情况下使方法可测试所需的方法更可见。此注释有一个可选的otherwise参数，如果不需要使方法在测试中可见，则可以指定该方法的可见性。Lint使用otherwise参数来强制实现预期的可见性。

实际上，这意味着您应该打开一个方法进行测试，@VisibleForTesting注释将显示警告。

例如

package com.mypackage;

public class ClassA {

    @VisibleForTesting(otherwise = VisibleForTesting.PRIVATE)
    static void myMethod() {

    }
}

当您在同一个包（com.mypackage）中调用ClassA.myMethod（）时，您将看到警告。

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

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

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

我建议您稍微重构一下代码。当你不得不开始考虑使用反射或其他类型的东西来测试你的代码时，你的代码出了问题。

你提到了不同类型的问题。让我们从私有字段开始。对于私有字段，我会添加一个新的构造函数并将字段注入其中。而不是：

public class ClassToTest {

    private final String first = "first";
    private final List<String> second = new ArrayList<>();
    ...
}

我会用这个：

public class ClassToTest {

    private final String first;
    private final List<String> second;

    public ClassToTest() {
        this("first", new ArrayList<>());
    }

    public ClassToTest(final String first, final List<String> second) {
        this.first = first;
        this.second = second;
    }
    ...
}

即使使用一些遗留代码，这也不会成为问题。旧代码将使用一个空构造函数，如果你问我，重构后的代码看起来会更干净，而且你可以在测试中注入必要的值，而无需反射。

现在谈谈私有方法。根据我的个人经验，当您必须存根一个私有方法进行测试时，该方法在该类中没有任何作用。在这种情况下，一种常见的模式是将其包装在一个接口中，如Callable，然后在构造函数中传递该接口（使用多构造函数技巧）：

public ClassToTest() {
    this(...);
}

public ClassToTest(final Callable<T> privateMethodLogic) {
    this.privateMethodLogic = privateMethodLogic;
}

我写的大部分内容看起来都是依赖注入模式。根据我的个人经验，它在测试时非常有用，我认为这种代码更干净，更容易维护。我对嵌套类也是这样说的。如果嵌套类包含大量逻辑，最好将其作为包私有类移动，并将其注入到需要它的类中。

在重构和维护遗留代码时，我还使用了其他几种设计模式，但这都取决于要测试的代码的情况。大多数情况下，使用反射并不是问题，但当您有一个经过严格测试的企业应用程序，并且在每次部署之前都要运行测试时，一切都会变得非常缓慢（这很烦人，我不喜欢这种东西）。

还有setter注入，但我不建议使用它。我最好使用构造函数，并在真正需要时初始化所有内容，留下注入必要依赖项的可能性。

下面的ReflectionTestUtil可以通用地用于测试私有方法的原子性。

import com.google.common.base.Preconditions;

import org.springframework.test.util.ReflectionTestUtils;

/**
 * <p>
 * Invoker
 * </p>
 *
 * @author
 * @created Oct-10-2019
 */
public class Invoker {
    private Object target;
    private String methodName;
    private Object[] arguments;

    public <T> T invoke() {
        try {
            Preconditions.checkNotNull(target, "Target cannot be empty");
            Preconditions.checkNotNull(methodName, "MethodName cannot be empty");
            if (null == arguments) {
                return ReflectionTestUtils.invokeMethod(target, methodName);
            } else {
                return ReflectionTestUtils.invokeMethod(target, methodName, arguments);
            }
        } catch (Exception e) {
           throw e;
        }
    }

    public Invoker withTarget(Object target) {
        this.target = target;
        return this;
    }

    public Invoker withMethod(String methodName) {
        this.methodName = methodName;
        return this;
    }

    public Invoker withArguments(Object... args) {
        this.arguments = args;
        return this;
    }

}

Object privateMethodResponse = new Invoker()
  .withTarget(targetObject)
  .withMethod(PRIVATE_METHOD_NAME_TO_INVOKE)
  .withArguments(arg1, arg2, arg3)
  .invoke();
Assert.assertNotNutll(privateMethodResponse)

我想分享一条关于测试的规则，这条规则尤其与本主题相关：

我认为你不应该为了更轻松地编写测试。

在其他帖子中有一些建议，说你应该调整原始类以测试私有方法-请先将此警告标记为红色。

如果我们将方法/字段的可访问性更改为包私有或受保护，只是为了让测试可以访问它，那么我们就违背了私有访问指令存在的目的。

当我们想要进行测试驱动的开发时，为什么要有私有字段/方法/类？那么，我们是否应该将所有内容都声明为私有的，甚至是公共的，这样我们就可以不费力地进行测试了-我不这么认为。

从另一个角度来看：测试不应影响生产应用程序的性能和执行。

如果我们仅仅为了更容易的测试而更改生产代码，这可能会在某种程度上影响性能和应用程序的执行。

如果有人开始将私有访问更改为包私有，那么开发人员最终可能会想出其他“巧妙的想法”，向原始类添加更多代码。这会给可读性带来额外的噪音，并会影响应用程序的性能。

随着私有访问更改为限制性较小的访问，我们为开发人员在应用程序的未来开发中滥用新情况提供了可能性。我们不是强迫他/她以正确的方式发展，而是用新的可能性引诱他/她，让他/她有能力在未来做出错误的选择。

当然，这条规则可能会有一些例外，但如果理解清楚，规则是什么，例外是什么？我们需要绝对确定我们知道为什么会引入这种例外。