Spring依赖注入中紧耦合如何对单元测试造成不利影响？

现在Mockito、ByteBuddy这类字节码增强工具确实支持直接mock普通具体类，看起来和mock接口的操作没什么区别，所以很多人会觉得“既然能mock具体类，那紧耦合也不影响单测”。但实际上能不能mock从来不是判断耦合影响的标准，紧耦合给单测带来的阻碍从来不是“完全没法写测试”，而是一堆你实际落地时绕不开的额外成本和隐性问题：

• Mock操作本身的额外兼容成本
  接口是纯抽象契约，没有构造逻辑、没有继承链约束、所有方法都是public的，任何mock工具处理接口时都不需要额外配置，也不会触发任何实现类的加载逻辑，零副作用。但mock具体类时会遇到各种边界问题：如果目标类是final类、包含final/static/private方法、写了静态初始化块、构造函数强依赖测试环境不存在的基础设施（比如需要真实数据库连接、要读本地磁盘配置、要初始化RPC客户端），就算你只是想mock这个类，默认的cglib mock实现直接就会失败，就算切换到支持mock final类的inline mock maker，静态块、构造函数里的副作用还是可能在类加载阶段触发，直接把单测搞挂。你为了mock一个根本不关心内部逻辑的依赖，要花时间处理一堆和测试目标完全无关的初始化问题，全是无意义的内耗。
• 实现细节渗透导致测试和实现强绑定
  直接依赖具体类时，IDE的自动补全会把这个实现类独有的、不属于公共契约的方法全部提示出来，开发者写业务代码时很容易顺手就调用这些实现特有的逻辑——比如你注入的是JDBC实现的订单仓储具体类，里面有个本来只供内部使用的执行原生SQL的public方法，你业务代码顺手写上了，等后面要把仓储换成MongoDB实现时，不仅业务代码要改，之前写的所有单测因为mock逻辑全绑死在JDBC实现类的具体方法上，也得全部跟着重写。更坑的是很多具体类的逻辑藏在继承链里，比如父类有个final方法会调用真实外部依赖，你mock的时候没覆盖到，单测跑的时候直接发了真实请求、连了真实数据库，排错要花掉大把时间。
• 测试行为和生产行为不一致的隐性风险
  面向接口注入时，Spring默认用JDK动态代理生成AOP对象，逻辑和生产环境运行的行为完全一致。如果直接注入具体类，Spring会用cglib生成子类做代理，遇到final类、final方法、非public方法时AOP逻辑根本不会生效，导致你单测里跑通的逻辑，到生产环境因为事务、权限校验、日志切面这类AOP逻辑没生效/异常生效直接出bug。为了避免这个问题，你写单测的时候还要额外核对代理逻辑是否符合预期，又是一笔额外的成本。

不是说所有场景都必须强制抽接口。如果依赖是无外部IO、没有多实现需求、没有复杂初始化逻辑的纯值对象或者工具类，直接依赖具体类完全没问题。Spring倡导面向接口编程的核心适用场景，是仓储、RPC客户端、第三方服务集成这类存在多实现可能、带外部副作用的组件，这类场景下紧耦合带来的长期维护成本、测试成本，远高于抽一层接口的成本。

内容的提问来源于stack exchange，提问作者Sahil