如何使用 JUnit 测试具有内部私有方法、字段或嵌套类的类？
为了能够运行测试而更改方法的访问修饰符似乎很糟糕。
【问题讨论】：
标签： java unit-testing junit tdd
测试私有方法的最佳方法是通过另一个公共方法。如果无法做到这一点，则以下条件之一为真：
【讨论】：
if (x == null) 永远无法到达，因为您已经在公共方法中进行了空检查。但是你应该清理私有方法，而不是发明不可能发生的测试用例。
通常，单元测试旨在测试类或单元的公共接口。因此，私有方法是您不希望显式测试的实现细节。
【讨论】：
私有方法由公共方法调用，因此公共方法的输入还应测试由这些公共方法调用的私有方法。当公共方法失败时，可能是私有方法失败。
【讨论】：
来自这篇文章：Testing Private Methods with JUnit and SuiteRunner（Bill Venners），你基本上有4个选择：
- 不要测试私有方法。
- 授予方法包访问权限。
- 使用嵌套测试类。
- 使用反射。
【讨论】：
我倾向于不测试私有方法。那里有疯狂。就个人而言，我认为你应该只测试你公开的接口（包括受保护的和内部的方法）。
【讨论】：
对于 Java，我会使用 reflection，因为我不喜欢仅仅为了测试而更改对声明方法的包的访问权限的想法。但是，我通常只测试公共方法，这也应该确保私有方法正常工作。
您不能使用反射从所有者类外部获取私有方法，私有修饰符也会影响反射
这不是真的。正如Cem Catikkas's answer 中提到的，您当然可以。
【讨论】：
System.Reflection 来完成它。” （显然你需要ReflectionPermission，但这通常不是问题。）
更新：
大约 10 年后，测试私有方法或任何无法访问的成员的最佳方法可能是通过 Manifold 框架中的
@Jailbreak。@Jailbreak Foo foo = new Foo(); // Direct, *type-safe* access to *all* foo's members foo.privateMethod(x, y, z); foo.privateField = value;这样您的代码就可以保持类型安全和可读性。没有设计妥协，没有为了测试而过度曝光的方法和领域。
如果您有一些遗留的 Java 应用程序，并且不允许更改方法的可见性，那么测试私有方法的最佳方法是使用 reflection。
在内部，我们使用助手来获取/设置 private 和 private static 变量以及调用 private 和 private static 方法。以下模式将让您做几乎所有与私有方法和字段相关的事情。当然，你不能通过反射改变private static final变量。
Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);
对于字段：
Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);
注意事项：
1.TargetClass.getDeclaredMethod(methodName, argClasses)让您查看private方法。同样的事情适用于getDeclaredField.
2.setAccessible(true)是用来玩私服的。
【讨论】：
在尝试过 Cem Catikkas 的 solution using reflection 用于 Java 之后，我不得不说他的解决方案比我在这里描述的更优雅。但是，如果您正在寻找使用反射的替代方法，并且可以访问您正在测试的源，这仍然是一个选择。
测试类的私有方法可能有好处，尤其是test-driven development，您希望在编写任何代码之前设计小型测试。
创建一个可以访问私有成员和方法的测试可以测试难以专门针对仅访问公共方法的代码区域。如果公共方法涉及多个步骤，则它可以包含多个私有方法，然后可以单独测试。
优点：
缺点：
但是，如果连续测试需要这种方法，这可能是一个信号，应该提取私有方法，可以用传统的公共方式进行测试。
这是一个令人费解的例子，说明它是如何工作的：
// 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。
【讨论】：
如果您尝试测试不愿意或无法更改的现有代码，反射是一个不错的选择。
如果该类的设计仍然灵活，并且您有一个复杂的私有方法想要单独测试，我建议您将其拉到一个单独的类中并单独测试该类。这不必改变原始类的公共接口；它可以在内部创建助手类的实例并调用助手方法。
如果您想测试来自辅助方法的困难错误条件，您可以更进一步。从帮助类中提取一个接口，在原类中添加一个公共的getter和setter来注入帮助类（通过其接口使用），然后将帮助类的mock版本注入到原类中，以测试原类如何响应助手的异常。如果您想测试原始类而不测试辅助类，这种方法也很有帮助。
【讨论】：
如果您想测试无法更改代码的遗留应用程序的私有方法，Java 的一个选项是jMockit，它允许您为对象创建模拟，即使它们是私有的类。
【讨论】：
Deencapsulation.invoke(instance, "privateMethod", param1, param2);
当我的类中有足够复杂的私有方法时，我觉得有必要直接测试私有方法，这就是代码异味：我的类太复杂了。
我解决此类问题的常用方法是梳理出一个包含有趣部分的新类。通常，这个方法和与之交互的字段，也许还有另外一两个方法可以被提取到一个新的类中。
新类将这些方法公开为“公共”，因此它们可用于单元测试。新旧类现在都比原来的类简单，这对我来说很棒（我需要保持简单，否则我会迷路！）。
请注意，我并不是建议人们不使用大脑就创建课程！这里的重点是使用单元测试的力量来帮助您找到好的新类。
【讨论】：
正如上面许多人所建议的，一个好方法是通过您的公共接口测试它们。
如果您这样做，最好使用代码覆盖工具（如 Emma）来查看您的私有方法是否实际上正在从您的测试中执行。
【讨论】：
如果您使用的是 JUnit，请查看 junit-addons。它具有忽略 Java 安全模型并访问私有方法和属性的能力。
【讨论】：
首先，我要抛出这个问题：为什么您的私人成员需要隔离测试？它们是否那么复杂，提供如此复杂的行为以至于需要在公共表面之外进行测试？这是单元测试，而不是“代码行”测试。不要为小事出汗。
如果它们大到足以使这些私有成员在复杂性上都是一个“单元”——考虑将这些私有成员重构出这个类。
如果重构不合适或不可行，是否可以在单元测试时使用策略模式来替换对这些私有成员函数/成员类的访问？在单元测试中，该策略将提供额外的验证，但在发布版本中，它将是简单的传递。
【讨论】：
测试私有方法会破坏类的封装，因为每次更改内部实现都会破坏客户端代码（在本例中是测试）。
所以不要测试私有方法。
【讨论】：
正如其他人所说...不要直接测试私有方法。以下是一些想法：
在单元测试中运行代码覆盖率。如果您发现方法未经过全面测试，请添加到测试中以提高覆盖率。以 100% 的代码覆盖率为目标，但要意识到您可能无法实现。
【讨论】：
您可以关闭反射的 Java 访问限制，这样私有就没有任何意义了。
setAccessible(true) 调用就是这样做的。
唯一的限制是 ClassLoader 可能不允许您这样做。
请参阅 Subverting Java Access Protection for Unit Testing (Ross Burton)，了解在 Java 中执行此操作的方法。
【讨论】：
在 C# 中您可以使用 System.Reflection，但在 Java 中我不知道。尽管无论如何我都想回答这个问题，因为如果您“觉得需要对私有方法进行单元测试”，我的猜测是还有其他问题……
我会认真考虑重新审视我的建筑......
【讨论】：
如果您的测试类与应测试的类在同一个包中怎么办？
但当然在不同的目录中，src 和 classes 用于您的源代码，test/src 和 test/classes 用于您的测试类。并让 classes 和 test/classes 在您的类路径中。
【讨论】：
我过去曾使用reflection 为 Java 执行此操作，在我看来这是一个很大的错误。
严格来说，您应该不编写直接测试私有方法的单元测试。您应该测试的是类与其他对象的公共契约；您永远不应该直接测试对象的内部结构。如果另一个开发人员想要对类进行小的内部更改，这不会影响类公共合同，那么他/她必须修改基于反射的测试以确保它有效。如果您在整个项目中反复执行此操作，那么单元测试将不再是衡量代码健康状况的有用指标，并开始成为开发的障碍，并让开发团队感到烦恼。
我建议改为使用 Cobertura 等代码覆盖率工具，以确保您编写的单元测试在私有方法中提供良好的代码覆盖率。这样，您可以间接测试私有方法的作用，并保持更高水平的敏捷性。
【讨论】：
我想测试私有方法的两个例子：
SecurityManager 未配置为防止这种情况时，它甚至可以用于查看私有方法）。我理解只测试“合同”的想法。但我不认为有人可以提倡实际上不测试代码 - 你的里程可能会有所不同。
因此，我的权衡是将 JUnit 与反射复杂化，而不是损害我的安全性和 SDK。
【讨论】：
private 不是唯一的选择。没有访问修饰符是package private，这意味着只要您的单元测试存在于同一个包中，您就可以对其进行单元测试。
要测试带有大而古怪的类的遗留代码，能够测试我正在编写的一个私有（或公共）方法通常非常有帮助。
我使用 Java 的 junitx.util.PrivateAccessor-package。许多有用的单行代码可用于访问私有方法和私有字段。
import junitx.util.PrivateAccessor;
PrivateAccessor.setField(myObjectReference, "myCrucialButHardToReachPrivateField", myNewValue);
PrivateAccessor.invoke(myObjectReference, "privateMethodName", java.lang.Class[] parameterTypes, java.lang.Object[] args);
【讨论】：
Class 作为您的第一个参数时，您只能访问 static 成员。
但如果你必须...
如果你使用的是JDK 1.3或更高版本，可以使用反射来颠覆 借助PrivilegedAccessor 的访问控制机制。 有关如何使用它的详细信息，请阅读this article。
如果您使用的是 JDK 1.6 或更高版本并且您使用 @Test，您可以使用Dp4j 在您的测试方法中注入反射。为了 具体使用方法见this test script。
【讨论】：
我只测试公共接口，但众所周知我会保护特定的私有方法，因此我可以完全模拟它们，或者添加特定于单元测试目的的额外步骤。一般情况是挂接我可以从单元测试中设置的标志，以使某些方法故意导致异常能够测试故障路径；异常触发代码仅在受保护方法的覆盖实现中的测试路径中。
不过，我尽量减少对此的需求，并且我总是记录确切的原因以避免混淆。
【讨论】：
我不确定这是否是一项好技术，但我开发了以下模式来对私有方法进行单元测试：
我不修改要测试的方法的可见性并添加其他方法。相反，我为我想要测试的每个私有方法添加了一个额外的公共方法。我将此附加方法称为Test-Port，并用前缀t_ 表示它们。这个Test-Port 方法然后简单地访问相应的私有方法。
此外，我在Test-Port 方法中添加了一个布尔标志，以决定是否从外部通过Test-Port 方法授予对私有方法的访问权限。然后在我放置的静态类中全局设置此标志，例如应用程序的其他全局设置。所以我可以在一个地方打开和关闭对私有方法的访问，例如在相应的单元测试中。
【讨论】：
Groovy 有一个bug/feature，通过它您可以像调用公共方法一样调用私有方法。因此，如果您能够在项目中使用 Groovy，那么您可以使用它来代替反射。以this page 为例。
【讨论】：
JML 有一个 spec_public 注释注释语法，允许您在测试期间将方法指定为公共：
private /*@ spec_public @*/ int methodName(){
...
}
http://www.eecs.ucf.edu/~leavens/JML/jmlrefman/jmlrefman_2.html#SEC12 讨论了此语法。还有一个将 JML 规范转换为 JUnit 测试的程序。我不确定它的效果如何或它的功能如何，但似乎没有必要，因为 JML 本身就是一个可行的测试框架。
【讨论】：
今天，我推送了一个 Java 库来帮助测试私有方法和字段。它的设计考虑了 Android，但它确实可以用于任何 Java 项目。
如果您有一些带有私有方法或字段或构造函数的代码，您可以使用BoundBox。它完全符合您的要求。 下面是一个访问 Android Activity 的两个私有字段以对其进行测试的测试示例：
@UiThreadTest
public void testCompute() {
// Given
boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());
// When
boundBoxOfMainActivity.boundBox_getButtonMain().performClick();
// Then
assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}
BoundBox 可以轻松测试私有/受保护的字段、方法和构造函数。你甚至可以访问被继承隐藏的东西。事实上，BoundBox 打破了封装。它会让你通过反射访问所有这些，但是在编译时会检查所有内容。
它非常适合测试一些遗留代码。小心使用它。 ;)
【讨论】：
私有方法被公共方法使用。否则，它们就是死代码。这就是为什么您要测试公共方法，断言公共方法的预期结果，从而断言它使用的私有方法。
在对公共方法运行单元测试之前，应通过调试来测试私有方法。
它们也可以使用测试驱动开发进行调试，调试单元测试直到满足所有断言。
我个人认为使用 TDD 创建类会更好；创建公共方法存根，然后使用 all 预先定义的断言生成单元测试，因此在编码之前确定方法的预期结果。这样，您就不会走上错误的道路，使单元测试断言适合结果。当您的所有单元测试都通过时，您的类就会变得健壮并满足要求。
【讨论】：
这是我测试私有字段的通用函数：
protected <F> F getPrivateField(String fieldName, Object obj)
throws NoSuchFieldException, IllegalAccessException {
Field field =
obj.getClass().getDeclaredField(fieldName);
field.setAccessible(true);
return (F)field.get(obj);
}
【讨论】：