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

Spring框架中的ReflectionUtilsJUnit中的ReflectionUtils

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

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

我不确定这是否是一种好的技术，但我开发了以下模式来单元测试私有方法：

我不修改要测试的方法的可见性，也不添加其他方法。相反，我为要测试的每个私有方法添加了一个额外的公共方法。我调用这个额外的方法TestPort，并用前缀t_表示它们。然后，此测试端口方法只需访问相应的私有方法。

此外，我向测试端口方法添加了一个布尔标志，以决定是否从外部通过测试端口方法授予对私有方法的访问权。然后在静态类中全局设置该标志，在该类中我放置了例如应用程序的其他全局设置。因此，我可以在一个地方打开和关闭对私有方法的访问，例如，在相应的单元测试中。

我和我的团队正在使用Typemock，它有一个API，允许您伪造非公共方法。

最近，他们增加了伪造不可见类型和使用xUnit的能力。

如果使用Spring，ReflectionTestUtils提供了一些方便的工具，可以帮助您以最小的工作量完成任务。例如，要在私有成员上设置模拟，而不必强制添加不需要的公共setter：

ReflectionTestUtils.setField(theClass, "theUnsettableField", theMockObject);

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

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

我使用的另一种方法是将私有方法更改为打包私有或受保护的方法，然后使用GoogleGuava库的@VisibleForTesting注释对其进行补充。

这将告诉使用此方法的任何人要小心，即使在包中也不要直接访问它。同样，测试类不需要在物理上位于同一个包中，而是位于测试文件夹下的同一包中。

例如，如果要测试的方法位于src/main/java/mybackage/MyClass.java中，那么您的测试调用应该位于src/test/java/mypackage/MiClassTest.java中。这样，您就可以访问测试类中的测试方法。