@nested 注解用于构建业务语义化的测试层级结构，外层类声明公共 fixture，每个非静态内部嵌套类代表独立业务阶段并拥有专属生命周期，配合 @displayname 和树形报告提升可读性与可维护性。
JUnit 5 的 @Nested 注解专为表达测试逻辑的层级结构而设计，特别适合模拟真实业务中“模块 → 子模块 → 场景”的嵌套关系。它让测试类本身成为可读性高、组织清晰的“文档”，而非单纯执行容器。
用 @Nested 拆分业务维度，而非技术细节
嵌套测试类应反映业务语义，比如订单系统中“创建订单”“支付流程”“发货校验”是天然层级，而不是按“单元测试”“集成测试”来分。每个 @Nested 类代表一个独立但有上下文依赖的业务阶段。
- 外层类只声明公共 fixture（如共享的 mock 对象或测试数据工厂），不写具体测试方法
- 每个
@Nested类用@BeforeEach设置该层级专属前置条件（例如：先创建草稿订单，再进入支付子流程） - 避免跨层级调用 —— 嵌套类之间不互相访问字段或方法，靠构造参数或静态工具传递必要状态
配合内部类与非静态限定，保障隔离与可读性
@Nested 类必须是非静态内部类，这样它能访问外部测试类的实例变量（如 sharedService），同时又因每次测试运行都会新建外层实例，天然隔离不同测试套件的状态。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 不要用
static修饰@Nested类，否则无法访问外层实例成员，也失去生命周期绑定意义 - 可在嵌套类里定义自己的
@Test方法和@BeforeEach，它们仅作用于本层级上下文 - IDE 和构建工具（如 Maven Surefire）会将嵌套结构渲染为树形报告，例如：
OrderServiceTest > PaymentFlow > whenPaySuccessThenOrderConfirmed
用 @DisplayName 提升业务可读性
直接用中文或带空格的描述命名 @Nested 类和测试方法，配合 IDE 的测试导航，一眼看懂覆盖了哪些业务路径。
- 在类上加
@DisplayName("退款审核流程")，比RefundReviewTest更贴近需求文档 - 测试方法也可用
@DisplayName("拒绝理由为空时应抛出异常")，无需拘泥于 camelCase 命名约束 - 注意：JUnit 默认用类/方法名生成显示名，
@DisplayName是覆盖行为，不是补充
慎用嵌套深度，三层以内最易维护
过度嵌套（如 A → B → C → D）会增加理解成本，且 JUnit 不支持四层及以上嵌套（编译通过但运行时忽略深层 @Nested）。
- 推荐结构：顶层类 = 主业务实体（如
OrderServiceTest），第二层 = 核心流程（如CreateOrder、CancelOrder），第三层 = 异常分支或边界场景（如WhenInventoryInsufficient） - 若某子流程本身足够复杂（如“跨境支付”含汇率、报关、退税多个环节），建议拆为独立顶级测试类，通过命名体现归属（如
CrossBorderPaymentTest） - 所有嵌套类需显式标注
@Nested，即使只是占位逻辑分组
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
