单元测试中暴露自动装箱/拆箱bug的关键是主动构造null、边界值和混合类型场景，重点覆盖包装类为null赋值、boolean条件判断、double三元运算、集合取值直赋基本类型四类高危用例，并结合assertj断言、mockito显式注入null及静态分析工具实现双重保障。
单元测试中暴露自动装箱/拆箱隐蔽 Bug 的关键，不是等它崩溃，而是主动构造 null、边界值和混合类型场景，让问题在测试阶段浮出水面。
重点覆盖四类高危测试用例
自动拆箱导致的 NPE 往往不发生在你写的代码行，而是在编译器悄悄插入的 intValue()、booleanValue() 调用处。测试必须覆盖这些“看不见的调用点”：
-
包装类为 null 时参与赋值：如
Integer age = null; int a = age;—— 测试需显式传入null并断言是否抛出NullPointerException -
条件判断中直接使用 Boolean：如
if (status) { ... }（status是Boolean）—— 测试应传入null，验证是否崩溃而非静默跳过 -
三元运算混用包装类与基本类型：如
double result = flag ? value : 0.0;（value是Double）—— 测试value = null时是否触发doubleValue()异常 -
集合取值后直赋基本类型：如
int score = list.get(0);（list是List<integer></integer>）—— 测试列表首项设为null，确认是否在赋值瞬间失败
用 AssertJ 或 JUnit 5 断言隐式行为
避免只检查结果正确性，要验证执行路径是否安全。推荐写法：
- 用
assertThatThrownBy(() -> methodUnderTest()).isInstanceOf(NullPointerException.class)显式捕获预期异常 - 对可能为空的字段，用
assertThat(obj.getAge()).isNotNull()先保底，再做数值断言 - 比较包装类值时，统一用
assertThat(a).isEqualTo(b)（AssertJ 内部调用Objects.equals），不依赖==
Mock 返回值时警惕自动装箱陷阱
用 Mockito 模拟方法返回包装类时，容易忽略 null 风险：
- 错误写法：
when(service.findCount()).thenReturn(100);—— 这会自动装箱为Integer，但掩盖了真实返回null的可能性 - 正确做法：
when(service.findCount()).thenReturn(null, 100, -1);主动注入null和边界值，覆盖拆箱全路径 - 数据库层模拟（如 MyBatis）时，在测试配置中启用
jdbc:columnLabel=COALESCE(age, null)类似逻辑，确保映射字段可空
静态分析 + 测试覆盖率双保险
单靠人工写用例易遗漏。建议组合使用：
- 启用 IntelliJ 的 “Boxing/unboxing may occur” 警告，并在 CI 中用
gradle test前加-Xlint:all编译参数，让 javac 报出潜在装箱点 - 用 JaCoCo 检查测试是否覆盖了含包装类字段的 getter/setter、DTO 构造、JSON 反序列化入口 —— 这些地方最容易漏掉 null 校验
- 对核心业务方法，添加一行注释说明：“本方法接收 Integer 参数，已确保非空或内部判空”，形成团队契约
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
