JUnit 5 中 @Nested 与 @ParameterizedTest 组合构建“业务维度×数据维度”双重验证结构：外层 @Nested 划分业务阶段（如支付流程），内层 @ParameterizedTest 覆盖该阶段数据变体，并通过 @DisplayName 和层级报告实现测试即文档。
在 JUnit 5 中，把 @Nested 和 @ParameterizedTest 组合使用，不是简单叠加，而是构建“业务维度 × 数据维度”的双重验证结构——外层用嵌套表达业务阶段，内层用参数化覆盖数据变体，真正实现高保真、易维护的业务验证。
用 @Nested 划分业务层级，每个子类专注一个语义场景
比如订单系统中，“创建订单”“支付流程”“发货校验”是天然的业务阶段。每个 @Nested 类应代表一个完整、独立的业务上下文：
- 必须是非静态内部类，才能访问外层实例变量（如共享的
orderService或测试数据工厂） - 外层类只声明公共 fixture（如 mock 的仓储、通用配置），不写
@Test方法 - 每个
@Nested类内用@BeforeEach设置本阶段专属前置条件（例如：先调用createDraftOrder()，再进入支付子流程） - 避免跨嵌套类访问字段或方法，状态传递靠构造参数或静态工具类，保障隔离性
在每个 @Nested 类里用 @ParameterizedTest 覆盖该阶段的数据变体
同一业务阶段下，往往存在多种合法/非法输入组合。这时不要为每种情况写单独 @Test，而应在对应 @Nested 类中启用参数化：
- 选
@CsvSource处理多字段组合（如"SUCCESS, 100.00, CONFIRMED"），适合边界值、状态迁移类验证 - 选
@MethodSource构造复杂对象（如传入预设的PaymentRequest实例），适合含嵌套结构或需定制逻辑的数据 - 慎用
@ValueSource，它只适合单值简单枚举（如支付渠道名"alipay", "wechat"），无法表达关联字段 - 所有参数化方法都应加
@DisplayName，例如@DisplayName("不同折扣率对最终金额的影响")，让报告一眼可读
配合 @DisplayName 和树形报告，让测试即文档
IDE 和 Maven Surefire 会将嵌套结构渲染为层级路径，例如：
立即学习“Java免费学习笔记（深入）”；
OrderServiceTest > PaymentFlow > whenPaySuccessThenOrderConfirmed这个路径本身就是一个业务用例描述。为此：
- 在外层测试类上加
@DisplayName("订单全链路业务验证") - 每个
@Nested类标注中文业务名，如@DisplayName("退款审核流程") - 每个
@ParameterizedTest方法也加@DisplayName，说明这组参数验证哪条规则（如"超时未审核自动关闭申请"） - 不依赖默认类名生成显示名，因为
RefundReviewTest不如退款审核流程直观
控制嵌套深度，三层以内最实用
过度嵌套（如 A → B → C → D）会显著降低可读性和调试效率。推荐实践：
- 一级：按主业务域划分（如
OrderServiceTest） - 二级：按核心流程划分（如
CreationFlow、PaymentFlow、RefundFlow） - 三级：按关键分支或角色视角划分（如
WhenAdminApproves、WhenCustomerCancels），仅在必要时引入 - 超过三层时，优先考虑拆分为多个顶层测试类，或用测试组（
@Tag）替代深层嵌套
