集成测试中验证继承体系的核心是检验行为一致性、类型兼容性与多态调用是否按预期工作，重点检查父类契约是否被子类遵守、运行时分发是否准确、系统整体行为是否稳定，覆盖多态协作场景而非孤立类调用。
在集成测试中验证继承体系的正确性，核心不是测“能不能编译通过”，而是检验继承带来的行为一致性、类型兼容性与多态调用是否按预期工作。重点在于：父类契约是否被子类真正遵守，运行时类型分发是否准确，以及扩展后系统整体行为是否稳定。
覆盖关键多态行为：统一接口 + 不同实现
继承的价值常体现在“用父类引用操作不同子类实例”这一能力上。集成测试应构造真实协作场景，而非孤立调用单个类。
- 定义一个典型业务入口方法，参数类型为父类（如 PaymentProcessor），内部调用 process() 方法
- 准备多个子类实例（CreditCardProcessor、PayPalProcessor、AlipayProcessor），全部注入或传入该方法
- 验证每次调用都成功执行，且各自日志、外部依赖（如模拟的支付网关响应）、返回结果符合该子类语义（例如信用卡扣款含 CVV 校验，支付宝需跳转 URL）
- 避免只测“不抛异常”，要测“做对了什么事”——这才是继承体系落地的真实价值
校验里氏替换原则（LSP）的实际表现
LSP 不是理论空谈，它在集成测试中体现为：任何子类对象替换父类对象后，原有业务流程不崩溃、不逻辑错乱、不静默失败。
- 复用已有通过测试的父类使用场景（比如订单结算服务依赖 DiscountPolicy），将原用的 FixedAmountDiscount 替换为新加入的 SeasonalPercentageDiscount
- 检查整个结算链路是否仍能完成：库存扣减、价格计算、发票生成、通知发送等环节无 NPE、类型转换异常或数值溢出
- 特别关注子类重写的方法是否改变了前置条件（如要求 price > 0）或削弱了后置条件（如本该返回非 null 却返回 null）——这些都会在集成流中暴露为下游空指针或业务中断
验证类型安全边界与向下转型风险
继承体系一旦变复杂，开发中容易出现 instanceof 和强制转型。集成测试要主动暴露这类脆弱点，而不是回避它。
- 编写测试用例，故意向期望父类参数的方法传入一个“不该出现”的子类（例如向仅支持国内支付的 DomesticPaymentService 传入 InternationalWireTransfer）
- 观察系统是否给出清晰错误（如 IllegalArgumentException 或自定义业务异常），而非在深层调用中抛出 ClassCastException 或产生错误账务
- 若业务逻辑确实需要区分类型（如导出报表时按动物类型渲染不同字段），则测试应覆盖转型后的字段读取、序列化、前端展示全流程，确保 getAdditionalInfo() 等子类特有方法在集成上下文中可安全访问
结合密封类（Sealed Classes）验证可扩展性控制
Java 17+ 密封类让继承关系显式可控。集成测试可验证这种设计约束是否在运行时生效，尤其当引入 non-sealed 子类时。
- 若父类 Shape 是 sealed，且只允许 Circle、Rectangle、Polygon，则测试应确认：尝试动态加载或反射创建第四个子类会失败（如触发 NoClassDefFoundError 或模块限制异常）
- 对声明为 non-sealed 的 Polygon，测试其子类（如 RegularPolygon）能否被 Spring 正确扫描、注入并参与图形渲染流水线，且不影响其他 Shape 子类的原有功能
- 检查 JSON 序列化/反序列化（如 Jackson）是否能根据类型信息正确绑定到对应子类——这属于继承体系在跨层数据流转中的完整性验证
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
