java - 使用 Mockito 进行单元测试时避免 final方法？

Question

<分区>

Answer 1

final 方法在一般情况下绝对不是坏习惯:它们传达了关于方法的行为和语义的特定信息——也就是说，任何调用该方法的人都将获得该实现。 这正是您试图通过模拟颠覆的属性，因为您正在通过(动态生成的)子类覆盖最终实现以执行 stub 行为。

为此，如果你有一个你控制的实现，你试图用一个 stub 替换测试，它可能不应该是final，因为你把它当作一个非 final 方法自己在你的测试中。您的测试是您的组件的另一个用户，您可以针对该用户进行相应的设计。

在您无法控制的实现中，例如第三方库，PowerMock是模拟构造函数以及 private、static 和 final 方法的普遍接受的解决方案，可能在 final 中类。不过，PowerMock 确实存在一些危险:

• mock 有额外的复杂性:PowerMock 通过一个重写类本身的特殊类加载器工作，而不是通过 Java 的 OOP 方法分派(dispatch)，因此您必须显式列出调用 的类final 和 static 方法，以便 Powermock 可以替换这些调用。
• 如果您这样做，模拟您无法控制的类会带来额外的风险:如果 API 或实现以不兼容的方式发生变化，您可能会处于不利的境地。
• 通过违反 final 修饰符的语义，它可能会使您的代码更难阅读 — 您声明该方法具有一种定义明确的可预测行为，然后围绕您自己的声明进行工作。

---

就“最佳实践”而言，真正的最佳实践是 OOP 原则 jgitter上面提到:“Program to interfaces, not implementations.”通过依赖显式接口(interface):

• ...您非常清楚与您交互的对象的契约(Contract)。
• ...您可以自由地对方法进行 stub 和验证，而无需涉及final 方法、测试不可见的方法或methods in superclasses not visible to the test 等实现细节。 . Final 方法特别隐蔽，因为 Mockito can't warn you about them .
• ...您可以轻松更改实现，包括改进的 future 实现、Mockito 生成的模拟，如您在此处或 full fake implementations for testing .

也就是说，Mockito stub 具体类的简便性使其成为一个诱人的选择，但请注意，最简单的语义正确答案 可能只是删除 final来自需要 stub 的特定方法。