1. 为什么断言是测试的灵魂
在单元测试的世界里，断言（Assertion）就像交通信号灯——它明确告诉你当前代码是"通行"还是"停止"。想象一下，如果没有红绿灯的路口会多么混乱，同样，没有断言的测试就像没有检查点的生产线，你永远不知道产品是否合格。
JUnit 5作为Java生态中最主流的测试框架，其断言机制经历了彻底的重构。与JUnit 4相比，它不再依赖org.junit.Assert类，而是通过org.junit.jupiter.api.Assertions提供了一套现代化的API。这个变化不仅仅是包名的改变，更代表着测试理念的进化：
- 链式调用：支持
assertXXX().withMessage()的流畅写法 - 延迟求值：通过lambda表达式避免不必要的字符串拼接开销
- 组合断言：支持多个条件的组合验证
- 异常处理：更优雅的异常断言方式
// JUnit 4 vs JUnit 5断言对比 assertEquals(expected, actual); // JUnit4 assertEquals(expected, actual, "自定义错误信息"); // JUnit52. 基础断言：测试世界的ABC
2.1 相等性断言：assertEquals的七十二变
assertEquals是最常用的断言方法，但它的使用技巧远比表面看到的丰富。当比较浮点数时，第三个参数delta才是关键：
// 比较0.1和0.2，允许0.15的误差范围 assertEquals(0.1, 0.2, 0.15); // 通过 assertEquals(0.1, 0.2, 0.05); // 失败对于数组比较，assertArrayEquals会逐个元素比对，而assertEquals只会比较引用地址。实际项目中，我遇到过因为用错方法导致测试误判的惨痛教训：
int[] expected = {1, 2, 3}; int[] actual = {1, 2, 3}; assertArrayEquals(expected, actual); // 正确方式 assertEquals(expected, actual); // 危险！可能误判2.2 布尔断言：assertTrue的认知误区
很多开发者习惯这样写断言：
assertTrue(result == expected);这其实是反模式！正确的做法是直接使用assertEquals，因为当断言失败时，前者只会显示"expected true but was false"，而后者会显示具体的期望值和实际值。这个细节在调试复杂测试时能节省大量时间。
2.3 空值断言：null检查的艺术
assertNull和assertNotNull看似简单，但在实际使用中有几个关键点：
- 对于可能为null的对象，先
assertNotNull再操作，避免NPE - 使用
Optional时，assertNotNull(optional.get())是危险操作 - 集合判空应该用
assertTrue(collection.isEmpty())而非assertNull
经验法则：在测试中，明确区分"不存在"和"为空"两种状态，这能避免很多边界条件问题。
3. 高级断言技巧：像专家一样测试
3.1 异常断言：从try-catch到assertThrows
JUnit 5彻底革新了异常测试方式。对比以下两种写法：
// 旧方式（JUnit4） @Test(expected = IllegalArgumentException.class) public void testException() { methodThatShouldThrow(); } // 新方式（JUnit5） @Test void testException() { Exception exception = assertThrows(IllegalArgumentException.class, () -> methodThatShouldThrow()); assertEquals("错误消息", exception.getMessage()); }新方式不仅能验证异常类型，还能检查异常消息、原因等细节。更重要的是，它解决了旧方式无法精确控制异常抛出位置的问题。
3.2 超时断言：assertTimeout的微妙之处
处理超时测试时，assertTimeout和assertTimeoutPreemptively有本质区别：
| 方法 | 执行策略 | 适用场景 |
|---|---|---|
assertTimeout | 等待任务完成，然后检查是否超时 | 需要确保测试完整性 |
assertTimeoutPreemptively | 超时立即终止测试 | 避免长时间阻塞 |
// 会执行完再判断，适合需要清理资源的测试 assertTimeout(Duration.ofSeconds(2), () -> { // 耗时操作 }); // 超时立即终止，适合可能死循环的情况 assertTimeoutPreemptively(Duration.ofSeconds(2), () -> { // 可能无限循环的代码 });3.3 组合断言：assertAll的威力
当需要验证多个条件时，传统的做法是写多个断言，但这样会导致第一个失败后后续断言不执行。assertAll解决了这个问题：
assertAll("用户信息校验", () -> assertEquals("张伟", user.getName()), () -> assertEquals(30, user.getAge()), () -> assertTrue(user.isActive()) );这个断言会执行所有子断言，然后汇总所有失败信息。在实际项目中，这能极大提高测试效率——你不需要反复运行测试来发现多个问题。
4. 自定义断言：打造领域专属测试语言
4.1 创建自定义断言类
当项目有特定领域的验证逻辑时，可以创建领域专属断言。例如电商系统中的价格断言：
public class PriceAssert { private final BigDecimal actual; private PriceAssert(BigDecimal actual) { this.actual = actual; } public static PriceAssert assertThat(BigDecimal actual) { return new PriceAssert(actual); } public PriceAssert isPositive() { assertTrue(actual.compareTo(BigDecimal.ZERO) > 0, "价格应该是正数"); return this; } public PriceAssert hasDiscount(BigDecimal originalPrice) { assertTrue(actual.compareTo(originalPrice) < 0, "折扣价应低于原价"); return this; } } // 使用示例 @Test void testPrice() { BigDecimal discountPrice = product.getPrice(); PriceAssert.assertThat(discountPrice) .isPositive() .hasDiscount(new BigDecimal("100.00")); }4.2 与AssertJ结合使用
虽然JUnit 5的断言已经很强大，但与AssertJ结合能达到更好的可读性：
import static org.assertj.core.api.Assertions.*; @Test void testWithAssertJ() { List<String> names = getNames(); assertThat(names) .hasSize(3) .contains("Alice", "Bob") .doesNotContain("Mallory"); }这种流畅接口(fluent interface)的写法特别适合复杂对象的断言。在我的一个项目中，使用AssertJ后测试代码的可读性提升了40%。
5. 断言最佳实践：从坑里爬出来的经验
5.1 错误消息的艺术
好的错误消息能节省大量调试时间。比较以下两种写法：
// 差：无信息量 assertTrue(user.isActive()); // 好：包含上下文 assertTrue(user.isActive(), "用户" + user.getId() + "应该是活跃状态");JUnit 5支持延迟消息生成，避免不必要的字符串拼接：
assertTrue(user.isActive(), () -> "用户" + user.getId() + "应该是活跃状态");5.2 避免过度断言
断言不足会导致测试不充分，但过度断言同样有害。典型的过度断言包括：
- 断言与测试目标无关的字段
- 断言永远不会失败的场景
- 重复断言相同逻辑
一个好的经验法则是：每个测试方法应该只验证一个明确的行为或属性。
5.3 性能敏感测试的断言技巧
在性能测试中，断言本身可能成为瓶颈。以下是一些优化技巧：
- 使用
assertTimeoutPreemptively而非assertTimeout - 避免在热路径中使用复杂对象断言
- 对于大量数据验证，考虑抽样检查而非全量断言
// 性能优化的断言示例 List<Data> hugeList = generateHugeList(); // 只检查首尾和中间若干元素 assertAll( () -> assertEquals(expectedFirst, hugeList.get(0)), () -> assertEquals(expectedMiddle, hugeList.get(hugeList.size()/2)), () -> assertEquals(expectedLast, hugeList.get(hugeList.size()-1)) );5.4 测试数据准备与断言分离
保持测试的"准备-执行-断言"三段式结构：
@Test void testOrderTotal() { // 准备 Order order = new Order(); order.addItem(new Item("Book", 50.00)); order.addItem(new Item("Pen", 10.00)); // 执行 BigDecimal total = order.calculateTotal(); // 断言 assertEquals(new BigDecimal("60.00"), total); }这种结构使测试更易于理解和维护。在实际代码审查中，我经常建议开发者保持这种清晰的结构。
