junit 5 的 @nested 注解用于按业务语义分组测试，每个非静态内部类代表独立上下文，支持专属生命周期管理与清晰命名，实现测试结构与逻辑层级对齐。
JUnit 5 的嵌套测试（@Nested）专为表达“类内逻辑分组”而设计，适合把一个业务对象的多个行为维度清晰拆解，比如“订单创建”可细分为“正常流程”“库存不足时”“用户权限异常时”等子场景。它不是为了套娃写测试，而是让测试结构与被测逻辑的语义层级对齐。
用 @Nested 拆解真实业务维度
嵌套类必须是非静态内部类，每个 @Nested 类代表一个独立的测试上下文，可拥有自己的 @BeforeEach、@AfterEach 和字段初始化逻辑。例如订单服务：
-
当订单状态为 PENDING 时—— 嵌套类负责所有 PENDING 相关操作（如支付、取消） -
当订单状态为 PAID 时—— 另一个嵌套类专注已支付后的发货、退款逻辑 -
边界条件—— 单独嵌套类集中处理空参数、非法 ID、并发修改等通用异常流
共享状态与隔离边界要手动控制
外层测试类的字段不会自动继承给嵌套类，但你可以显式复用；关键是要避免隐式共享导致测试污染：
- 在嵌套类里声明自己的
OrderService实例或 Mock 对象，而不是共用外层字段 - 若需预设数据，用
@BeforeEach在每个嵌套类中独立准备，不要依赖外层@BeforeAll的一次性 setup - IDEA 或 Maven 执行时，会把每个
@Nested类当作独立测试容器，失败时能精准定位到具体子场景
配合生命周期注解提升可读性
嵌套结构天然适配 JUnit 5 生命周期管理：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 外层
@BeforeAll可做一次性的重资源初始化（如启动嵌入式数据库） - 每个嵌套类的
@BeforeEach负责该维度下的干净状态（如新建一个待测订单） - 嵌套类内的
@Test方法只关注单一动作和断言，不掺杂 setup/cleanup
命名即文档：用类名表达测试意图
嵌套类名应是完整句子或短语，直接说明它覆盖哪一类行为。IDE 显示测试树时，会拼接出可读路径，例如：
OrderServiceTest
├── 当订单状态为 PENDING 时
│ ├── 应允许成功支付
│ └── 应拒绝重复支付
├── 当订单状态为 PAID 时
│ ├── 应允许发货
│ └── 应拒绝再次支付
└── 边界条件
├── 订单ID为空时抛出异常
└── 并发修改时返回乐观锁错误
这种结构不需要额外注释，就能让任何人一眼看懂测试覆盖了什么、缺了什么。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
