高质量断言应清晰表达“测什么、为什么测、错在哪”，用自然语言失败消息、流式API（如AssertJ）、显式上下文和精准静态导入，避免裸assertEquals与通配符导入。
高质量的断言不是“让测试跑通”，而是让别人（包括未来的你）一眼看懂“测什么、为什么这么测、错在哪”。核心是把断言变成一句可读的判断句，而不是一串参数拼凑的函数调用。
明确表达预期意图
避免裸写 assertEquals(expected, actual)，尤其当 expected 是字面量时。IDE 不会告诉你这个 10.0 代表什么。
- 给每个断言加清晰的失败消息，用自然语言说明业务含义，比如：
“VIP用户下单满200元应享15%折扣” - 在测试准备阶段显式设置上下文（如 user.setLevel(VIP)、order.setAmount(200.0)），让断言消息和前置条件形成逻辑闭环
- 数值比较慎用浮点数等号判断，始终带上 delta（如 assertEquals(30.0, discount, 0.001)）并体现在消息里：“允许±0.001误差”
优先使用 AssertJ 的流式断言
把断言主语前置，动词跟上，结果收尾，读起来像句子：
- 用 assertThat(actual).isEqualTo(expected) 替代 assertEquals(expected, actual)，彻底规避“期望/实际”顺序混淆
- 集合操作直接写 assertThat(items).contains("apple").hasSize(3).doesNotContain(null)
- 字符串校验用 assertThat(name).isNotBlank().startsWith("U").endsWith("r")
- 失败时自动输出结构化差异（如 List 实际内容 vs 期望元素），无需额外日志
静态导入要克制且精准
静态导入是为了减少干扰，不是为了省字符数。
- 只导入真正高频、语义无歧义的方法：assertEquals、assertTrue、assertThat、assertThrows
- 绝对避免 import static org.junit.jupiter.api.Assertions.* —— 会污染命名空间，导致 IDE 补全混乱、方法来源难追溯
- 如果项目已用 AssertJ，就统一用 import static org.assertj.core.api.Assertions.*，不再混用 JUnit 原生断言
按场景选对断言类型
不同数据结构有专属断言方式，硬套 assertEquals 反而掩盖问题。
- 验证异常：用 assertThrows(NullPointerException.class, () → obj.doSomething())，再链式检查 e.getMessage()
- 验证空值：用 assertNotNull(result, "服务返回对象不应为空")，比 assertTrue(result != null) 更直白
- 验证布尔逻辑：用 assertTrue(order.isEligibleForFreeShipping(), "订单金额超299应包邮")，不写成 assertEquals(true, ...)
- 验证对象状态：用 assertThat(user).extracting("name", "age").containsExactly("张三", 28)
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
