面向接口编程是提升可测试性的核心手段，通过解耦依赖与实现，使单元测试能绕过外部依赖、专注业务逻辑验证，并支持环境隔离、灵活扩展与稳定契约。
面向接口编程是让多态真正服务于可测试性的核心手段。它把“依赖什么”和“谁来实现”彻底分开，测试时就能绕过外部依赖，专注验证业务逻辑本身。
让单元测试真正“单元”起来
业务代码只依赖接口，不依赖具体实现类，测试时就不用启动数据库、调用真实支付网关或发短信。
- 订单服务声明依赖 PaymentGateway 接口，测试时直接注入一个返回
true的内存实现，或用 Mockito 模拟行为 - DAO 方法返回类型写成 UserRepository，而不是
MySqlUserRepository；测试可用Map<String, User>存储代替 JDBC 连接 - 消息推送模块调用 NotificationService，测试时跳过短信通道，只校验通知内容是否符合规则、触发条件是否满足
- 避免在 service 方法里
new WechatPayGateway()——这种硬编码会让测试只能走集成路径，慢且容易失败
用接口隔离外部环境变化
不同环境需要不同行为，但业务逻辑不变。接口 + Spring Bean 管理，让切换实现变成配置级操作。
- 日志组件统一用 Logger 接口：开发环境用文件输出，测试环境用空实现（
NoOpLogger），生产环境对接 Elasticsearch - 导出功能通过 Exporter 接口统一入口，PDF 和 Excel 各自实现；新增 CSV 导出，只需加个新类，不改任何调用方代码
- 缓存策略按环境配置：本地用
CaffeineCache，预发/生产用RedisCache；切换靠@ConditionalOnProperty或配置文件控制
避免测试被实现细节绑架
接口契约稳定，测试就稳定；一旦暴露实现，测试就会随实现变动而频繁失效。
立即学习“Java免费学习笔记（深入）”；
- 接口方法命名聚焦行为，比如
export(ReportData data)，而不是exportToPdf(ReportData data)——后者把格式写死，后续加 Excel 就得改接口 - 参数和返回值用集合接口类型（
List<User>、Map<String, Object>），不用ArrayList或HashMap；将来换成不可变集合或流式响应，测试照常运行 - Java 8+ 的 default 方法可放通用逻辑，但如果发现多个实现共用大量相同代码，说明接口职责太重，该拆分——否则测试会因冗余逻辑变得难维护
测试驱动接口设计质量
写测试的过程，就是检验接口是否真正抽象到位的过程。好的接口，能让测试写得干净、覆盖准、改得少。
- 如果测试要反复 mock 多个方法、构造复杂入参，可能说明接口粒度太粗或职责不清
- 如果新增一种支付方式（如 Apple Pay）后，原有测试全部通过，只加几个新测试用例，说明接口契约合理、扩展友好
- 接口方法抛的异常类型要是明确的业务异常（如
InsufficientBalanceException），而不是泛泛的RuntimeException；测试才能精准断言错误场景
