接口更优，因其支持default方法免改实现类、天然多实现、增强重构兼容性；抽象类在状态共享时更安全，但扩展和组合能力弱。
接口与抽象类的测试，不是测“能不能跑通”，而是测“设计是否经得起变化”——重点验证它们在真实演进场景下的适应性、可维护性和扩展成本。下面从四个关键维度给出可落地的测试思路和操作方式。
看新增功能时，谁更少改代码
这是最直接的验证点。模拟业务迭代：比如给支付模块加“支持分期付款”能力。
- 如果用接口（如 Payment），只需在接口中新增 default 方法
supportInstallment()，所有已实现类自动获得该能力，无需修改任何子类 - 如果用抽象类（如 AbstractPayment），新增抽象方法会强制所有子类重写；加具体方法虽不强制，但若逻辑依赖新字段（如
installmentRate），就得改构造器和字段声明，波及全部子类
✅ 测试动作：写一个含 3 个实现类（微信、支付宝、银联）的小模块，分别用接口和抽象类实现，然后执行“加一个带默认行为的新方法”，统计需修改的文件数和风险点。
看多能力组合时，谁更自然
当一个类需要同时具备多种独立能力（比如“可退款 + 可对账 + 可异步通知”），就暴露本质差异。
立即学习“Java免费学习笔记（深入）”；
- 接口天然支持
implements Refundable, Reconcilable, Notifyable，语义清晰，无继承冲突 - 抽象类只能单继承，若把“退款逻辑”抽成另一个抽象类
AbstractRefundable，就无法同时继承两个父类，只能靠组合或重复代码
✅ 测试动作：定义三个行为接口，再写一个类同时实现它们；再尝试用抽象类模拟同样结构——你会立刻遇到“父类已占用 extends”的编译错误。
看状态共享需求下，谁更安全可控
如果多个子类必须共用某些运行时状态（如连接池、配置上下文、计数器），抽象类的优势就显现了。
- 抽象类可声明
protected ConnectionPool pool，通过构造器初始化，子类直接复用，状态生命周期统一管理 - 接口不能有实例变量，只能靠 static final 常量或外部传参，状态分散、易出错；default 方法里 new 对象又违背复用本意
✅ 测试动作：在抽象类中定义一个带初始值的 protected 字段，在子类中访问并修改它，观察是否真正共享；换成接口后，尝试用 static 字段模拟——你会发现线程安全、重置逻辑、测试隔离都变复杂了。
看重构兼容性时，谁更抗折腾
团队协作中，改动基类/接口常引发连锁编译失败。这里接口的 default 方法是“减震器”，抽象类则更刚性。
- 对接口增加 default 方法：已有实现类完全不受影响，CI 构建通过率 100%
- 对抽象类增加抽象方法：所有非抽象子类立即编译失败，必须同步更新；加 protected 方法虽不报错，但若被子类意外重写，可能破坏原有调用链
✅ 测试动作：用 CI 脚本自动化验证——先提交旧版本代码，再提交含新增抽象方法的抽象类变更，观察构建日志；对比同样语义的接口 default 方法变更，确认是否零失败。
不复杂但容易忽略：真正的优劣不在语法能否通过，而在你下次改需求时，是花 5 分钟加一行 default 方法，还是花半天梳理继承树、协调三个模块一起发版。
