Mockito不允许嘲笑最终方法.
在代码中使用最终方法被认为是不好的做法吗？为什么？

我不想仅仅为了使测试代码工作而改变实现细节,但是,测试框架通常会有这些规则来鼓励更好的编码实践.

解决方法:

最终的方法绝对不是一般的做法：它们传达了一个关于方法的行为和语义的特定信息 – 也就是说,任何调用该方法的人都将获得完全相同的实现.这正是您试图通过模拟颠覆的属性,因为您通过(动态生成的)子类重写最终实现来代替执行存根行为.

为此,如果您有一个实现,您可以控制您尝试使用存根替换测试,那么它可能不应该是最终的,因为您在测试中将其视为非最终方法.您的测试是组件的另一个用户,您可以相应地设计一个用户.

在您无法控制的实现中,例如第三方库,PowerMock是一种普遍接受的模拟构造函数的解决方案,以及私有,静态和最终方法,可能在最终类中.但是,PowerMock确实存在一些危险：

>模拟有额外的复杂性：PowerMock通过一个特殊的类加载器来重写类本身,而不是通过Java的OOP方法调度,所以你必须明确地列出调用最终和静态方法的类,因此Powermock可以替换那些电话.
>如果您这样做,则模拟无法控制的类会有额外的风险：如果API或实现以不兼容的方式更改,您可能会处于不利的位置.
>通过违反最终修饰符的语义,它可能使您的代码更难以阅读 – 您声明方法具有一个明确定义的可预测行为,然后解决您自己的声明.

就“最佳实践”而言,真正的最佳实践是OOP原则jgitter上面提到：“Program to interfaces, not implementations.”依靠显式接口：

> …你非常清楚你正在与之交互的对象的合同.
> …您可以*地存根和验证方法,而不涉及最终方法,测试不可见的方法或methods in superclasses not visible to the test等实现细节.最终方法特别隐蔽,因为Mockito can’t warn you about them.
> …您可以轻松更改实施,包括改进的未来实施,Mockito生成的模拟,如您所拥有,或full fake implementations for testing.

也就是说,Mockito存在具体类的简易性使其成为一个诱人的选择,但请注意,最简单的语义正确答案可能是从需要存根的特定方法中删除final.