私有方法被公共方法使用。否则，它们就是死代码。这就是为什么要测试公共方法，断言公共方法的预期结果，从而断言它使用的私有方法。

在公共方法上运行单元测试之前，应该通过调试来测试私有方法。

也可以使用测试驱动开发来调试它们，调试单元测试，直到满足所有断言。

我个人认为最好使用TDD创建类；创建公共方法存根，然后使用预先定义的所有断言生成单元测试，这样在编写代码之前就可以确定方法的预期结果。这样，就不会走上使单元测试断言符合结果的错误道路。然后，当所有单元测试通过时，您的类是健壮的并满足要求。

私有方法由公共方法调用，因此公共方法的输入也应测试这些公共方法调用的私有方法。当公共方法失败时，这可能是私有方法的失败。

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

所以不要测试私有方法。

我只测试公共接口，但众所周知，我会保护特定的私有方法，因此我可以完全模拟它们，或者添加特定于单元测试目的的额外步骤。一般情况下，挂接我可以从单元测试中设置的标志，以使某些方法故意导致异常，从而能够测试故障路径；异常触发代码仅在受保护方法的重写实现中的测试路径中。

不过，我尽量不需要这样做，我总是记录下确切的原因，以避免混淆。

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

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

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

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（）时，您将看到警告。