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

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

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

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

所以不要测试私有方法。

对于Java，我会使用反射，因为我不喜欢仅仅为了测试而更改对声明方法的包的访问。然而，我通常只测试公共方法，这也应该确保私有方法正常工作。

不能使用反射从所有者类外部获取私有方法，私有修饰符也会影响反射

这不是真的。你当然可以，正如塞姆·卡提卡斯的回答中所提到的。

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

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

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

JML具有spec_public注释注释语法，允许您在测试期间将方法指定为public：

private /*@ spec_public @*/ int methodName(){
...
}

2.4隐私修改器和可见性中讨论了此语法。还有一个将JML规范转换为JUnit测试的程序。我不确定它的工作情况如何，或者它的功能是什么，但似乎没有必要，因为JML本身就是一个可行的测试框架。