optional是主动规避空指针的设计工具，测试需覆盖创建（ofnullable/null处理）、消费（get/orelse/ifpresent/map等边界行为）及外部交互（如dao/http空响应）三类边界，并避免语义矛盾与误用。
Optional 本身不捕获空指针异常，它是一种**主动规避空指针的设计工具**。测试它的边界条件，核心是验证你是否在正确场景下使用了 Optional，以及是否妥善处理了 empty() 和 present() 两种状态——而不是指望它“自动兜底” NullPointerException。
测试 Optional 的创建边界
重点检查哪些地方可能传入 null 却被错误地包装进 Optional，导致隐藏问题：
- 避免
Optional.of(null)：这会立即抛出NullPointerException，属于非法用法，单元测试中应明确验证该行为（用@Test(expected = NullPointerException.class)或 AssertJ 的assertThatThrownBy） - 改用
Optional.ofNullable(x)处理可能为 null 的输入，并为x == null和x != null分别写测试用例 - 例如：一个根据 ID 查询用户的方法返回
Optional<user></user>，需覆盖 ID 不存在（DB 返回 null →ofNullable得到 empty）、ID 存在（返回非 null User → 得到 present）两种情况
测试 Optional 的消费逻辑边界
真正容易出错的是对 Optional 的后续操作。要确保每种“解包”方式都经受住 empty 场景考验：
-
get()：仅在已确认isPresent()时调用；测试必须包含对 empty Optional 调用get()的场景——这会抛NoSuchElementException，不是 NPE，但属于逻辑错误，应有对应测试和防御性判断 -
orElse(T)/orElseGet(Supplier)：测试 empty 时是否返回默认值，present 时是否返回原始值（注意orElseGet的 Supplier 是否真的惰性执行） -
ifPresent(Consumer)：测试 empty 时不执行 Consumer，present 时准确执行——可配合 Mockito 验证 Consumer 是否被调用 -
map()/flatMap()：测试链式调用中某一步返回 null 时，是否自然转为 empty（map内部对 null 返回 empty），而非触发 NPE
测试与外部系统交互的边界
当 Optional 封装的是外部调用结果（如 DAO、HTTP Client），边界往往在“空响应”的语义上：
- 数据库查不到记录 → 返回
Optional.empty()（合理） - 远程 API 返回 404 或空 JSON → 你的客户端代码是否统一转为
Optional.empty()？需模拟这些 HTTP 响应并验证 Optional 状态 - 避免把“业务意义上的空”（如余额为 0）和“技术意义上的空”（对象引用为 null）混淆；Optional 应只表达“值是否存在”，不表达“值是否有意义”
不推荐的测试误区
有些做法看似在测 Optional，实则偏离本质：
- 给方法参数加
@NonNull+Optional<t></t>：语义矛盾。Optional 参数本身暗示“可选”，再要求非空反而增加调用方负担 - 在 service 层大量返回 Optional，却在 controller 层直接
get()—— 这等于把空指针风险后移，测试时容易漏掉 empty case - 用 Optional 包装集合（
Optional<list>></list>）：通常应返回空集合，而非 empty Optional；测试时要区分“无数据”和“查询失败”两种语义
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
