java单元测试命名与结构是影响可读性、可维护性和协作效率的关键实践：类名用“被测类名+test”，方法名用@displayname描述业务场景，@nested按业务语义分组，目录结构严格镜像源码，每个@test只验证单一意图。
Java 单元测试的命名与结构不是风格偏好问题，而是直接影响可读性、可维护性和协作效率的关键实践。命名不清，新成员看不懂测的是什么；结构混乱，改一个逻辑要翻五六个文件；两者叠加，测试很快沦为“存在即合理”的摆设。
测试类和方法名：用自然语言说清“谁在什么条件下做了什么”
类名以 被测类名 + Test 结尾，比如 UserService 对应 UserServiceTest；方法名不拼驼峰、不缩写，直接描述行为场景。JUnit 5 的 @DisplayName 是标配，支持空格和符号：
@Test @DisplayName("用户注册 - 当邮箱已存在时返回冲突状态")@Test @DisplayName("计算折扣 - 会员等级为VIP时应用85折 ✅")@Test @DisplayName("解析JSON - 输入空字符串时抛出IllegalArgumentException")
避免像 testCreateUserWithValidInput() 这类仅反映代码结构的名字——它没说明业务含义，也不体现失败价值。
测试结构分层：按职责边界组织嵌套，不是按技术层堆方法
用 @Nested 模拟业务语义分组，而不是把所有 Service 测试塞进一个大类。例如订单服务可这样组织：
-
@Nested @DisplayName("创建订单")→ 包含库存充足/不足、地址缺失等子场景 -
@Nested @DisplayName("取消订单")→ 包含已发货/未支付/超时等状态分支 -
@Nested @DisplayName("查询历史订单")→ 按时间范围、状态筛选、分页等维度拆
每个 @Nested 类内部再用 @BeforeEach 统一准备共用对象（如 mock 的 repository），避免重复初始化。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
目录与包结构：和源码严格对齐，拒绝“test 目录平铺”
测试类路径必须镜像 main 下的包结构：src/main/java/com/example/order/OrderService.java → src/test/java/com/example/order/OrderServiceTest.java。好处是：
- IDE 点击跳转直达对应测试，无需搜索
- 重构时移动类，测试自动跟随，不会断链
- CI 扫描覆盖率时能精准归因到模块
不要把所有测试塞进 com.example.test 这种顶层包里，那等于主动放弃结构化管理。
生命周期与断言：每个测试方法只验证一个明确意图
一个 @Test 方法只做三件事：准备输入（Given）、触发动作（When）、校验输出（Then）。不混入日志打印、sleep、多断言组合：
- 用
@BeforeEach做轻量初始化（new 对象、mock 创建） - 用
@AfterEach清理线程局部变量或临时文件，不用关数据库连接（单元测试不该连库） - 断言优先选语义化方法，如
assertThat(result).isNotNull().hasFieldOrProperty("id")，比多个assertEquals更易定位问题
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
