为什么建议在使用Mockito框架进行单元测试时使用接口?在单元测试中接口的确切用途是什么?
有两个原因:一个是理论上的，一个是实际的。
理论当使用mock时，您提供了在应用程序中其他地方存在(或将存在)的组件的测试双;存根时，您正在模拟实际实现可能具有的响应，并且在针对类的外部接口进行验证时。这使得对于接口的成功实现者应该做什么以及他们应该如何行为有一个清晰的定义变得非常重要，而不管当前的实现是什么:你正在提供一个不同的实现。
虽然您可以在具体类本身上逐个方法地记录实现的契约，但另一种记录和形式化组件的通用契约的方法是提取接口。虽然我不是前瞻性工作(请参阅YAGNI)的支持者，但是如果您要用另一个实现部分或完全替换当前的具体实现，那么这样做也会更清晰——此时您将有包括模拟在内的接口的三个实现，并且可能希望纯粹针对接口编写测试，并将每个实现分别传递给它们以进行验证/确认。
练习在内部，Mockito通过生成您要测试的类的子类来动态地创建您的test double。这意味着mock只能覆盖普通子类可以覆盖的行为，这可能会使mock不适合私有类、封装的嵌套类或内部类以及final类。此外，由于类似的原因，您将发现自己无法模拟静态方法、final方法和一些私有或受保护的方法(特别是在编译器生成合成方法的地方)。由于Mockito的语法和动态特性，Java不能在编译时警告或强制执行这些规则，并且Mockito不能总是在运行时检测违规。
然而，当模拟接口而不是具体实现时，Mockito可以避免很多麻烦。接口没有内部方法可见性限制或final方法，并且类型本身必须是公共的和非final的。因此，从实用的角度来看，接口而不是具体的类在简单和易于工作方面具有优势。