@Nested 注解通过非静态内部类实现测试场景分层，每层可定义专属生命周期方法并配合@DisplayName提升报告可读性，使测试结构精准映射业务语义。
JUnit 5 的 @Nested 注解是组织复杂测试逻辑最实用的方式之一，它让测试结构真正反映业务语义，而不是堆砌一堆平铺方法。
用 @Nested 拆分场景层级
一个功能往往有多个子行为，比如“用户注册”包含“邮箱格式校验”“密码强度检查”“重复邮箱拦截”等。把这些全写在同一个类里，方法名会越来越长，意图反而模糊。用 @Nested 可以按语义建子类：
- 每个嵌套类对应一个核心场景（如
CreateUser、UpdateUser） - 嵌套类内部再用 @Test + @DisplayName 描述具体条件分支
- 嵌套类可独立运行，IDE 和 Maven 都支持直接执行某一层级
嵌套类的生命周期与访问规则
嵌套类必须是非静态的内部类，这样才能访问外围测试类的实例变量和 @BeforeEach/@AfterEach 方法。例如：
- 外层 @BeforeAll 可做全局初始化（如启动测试数据库）
- 每层嵌套类可定义自己的 @BeforeEach，用于该场景专属准备（如预置测试用户）
- 嵌套类不能有 @BeforeAll/@AfterAll（除非是
static，但此时无法访问实例状态）
配合 @DisplayName 提升可读性
嵌套结构本身只是代码组织，真正让报告清晰的是显示名称。建议组合使用：
立即学习“Java免费学习笔记（深入）”；
- 外层类用 @DisplayName("用户管理")
- 嵌套类用 @DisplayName("注册流程")
- 测试方法用 @DisplayName("当邮箱已存在时返回冲突错误")
这样在 IntelliJ 或 Jenkins 报告中，路径就变成：用户管理 › 注册流程 › 当邮箱已存在时返回冲突错误——一眼看懂覆盖了什么。
实际写法示例
以下是一个简洁可用的结构模板：
@DisplayName("订单服务")class OrderServiceTest {
@Nested
@DisplayName("创建订单")
class CreateOrder {
@Test
@DisplayName("库存充足 → 订单创建成功")
void successWhenStockAvailable() { /* ... */ }
}
@Nested
@DisplayName("取消订单")
class CancelOrder { /* ... */ }
}
