私有方法只能在同一类中访问。因此，无法从任何测试类测试目标类的“私有”方法。一种方法是，您可以手动执行单元测试，也可以将方法从“私有”更改为“受保护”。

然后，受保护的方法只能在定义类的同一个包中访问。因此，测试目标类的受保护方法意味着我们需要在与目标类相同的包中定义测试类。

如果以上所有内容都不符合您的要求，请使用反射方式访问私有方法。

测试私有方法的最佳方法是通过另一个公共方法。如果无法做到这一点，则以下条件之一为真：

私有方法是死代码您正在测试的类附近有设计气味您尝试测试的方法不应是私有的

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

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

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

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

Spring框架中的ReflectionUtilsJUnit中的ReflectionUtils

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

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

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

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

正如上面许多人所建议的，一个好的方法是通过公共接口测试它们。

如果您这样做，最好使用代码覆盖工具（如EMMA）来查看您的私有方法是否确实在测试中执行。