高质量单元测试需“测得准、看得懂、稳得住”：覆盖业务状态流转与规则判断，用when_条件_then_结果命名，mock真实契约依赖，verify关键行为而非仅返回值。
高质量的业务单元测试用例，核心是“测得准、看得懂、稳得住”——准确覆盖业务逻辑，命名和结构清晰易读，不随业务代码变动而频繁失效。
紧扣业务场景设计测试用例
业务逻辑不是算法或工具类，它往往涉及状态流转、规则判断、外部依赖交互。测试前先厘清：这个方法在什么条件下成功？哪些输入会触发拒绝、降级或补偿？例如用户下单流程，需覆盖：
- 库存充足时正常创建订单并扣减
- 库存不足时抛出InsufficientStockException而非静默失败
- 优惠券已过期时跳过折扣计算，但不中断主流程
- 并发下单时，同一商品只允许一个成功（需结合@RepeatedTest或模拟锁机制验证）
用真实业务语言命名测试方法
避免testCreateOrder()这类模糊名称。推荐格式：when_业务条件_then_预期业务结果，例如：
- when_inventoryIsSufficient_then_orderCreatedAndStockDeducted()
- when_couponExpired_then_discountSkippedButOrderStillPlaced()
- when_userHasPendingRefund_then_newOrderRejectedWithClearMessage()
这样的命名让团队成员不看代码也能理解该测试守护哪条业务契约，CI失败时可快速定位影响范围。
隔离依赖，只测本职逻辑
业务类通常依赖DAO、RPC服务、配置中心等。单元测试中必须用Mockito等框架替换真实调用，但关键在于“模拟要贴近真实契约”：
- DAO层mock返回符合业务语义的数据（如userDao.findById(123)返回一个User.builder().status(ACTIVE).build()，而非空对象）
- RPC调用mock需覆盖成功、超时、限流、降级等典型响应，尤其注意异常类型是否与业务处理分支匹配
- 避免过度mock：不mock被测类自身的方法，不mock纯计算逻辑（如金额四舍五入），这些应直接验证
验证行为，不止验证返回值
业务方法常产生副作用，仅断言返回值远远不够。需结合verify()确认关键协作行为是否发生：
- 下单成功后，是否调用了stockService.deduct()？调用几次？参数是否正确？
- 风控拦截时，是否记录了审计日志（auditLogService.log()）？日志内容是否含用户ID和拦截原因？
- 异步任务是否提交到线程池（taskExecutor.submit()）？
这类验证确保业务流程链路完整，防止“返回对了，但关键动作漏了”的隐蔽缺陷。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
