JUnit中编写自定义断言需聚焦业务语义：通过静态工具类、AssertJ链式断言或自定义AbstractAssert子类实现高可读性，配合测试数据构建器形成语义闭环。
在 JUnit 中编写自定义断言函数，核心是让断言语义更贴近业务意图，而不是堆砌底层 `assertEquals` 或 `assertTrue`。Java 本身不支持像 Kotlin 那样直接扩展函数，但可通过静态方法 + 流畅 API 设计实现高可读性断言。
用静态工具类封装语义化断言
创建一个工具类（如 `Assertions`），提供带业务含义的静态方法。这些方法内部调用 JUnit 原生断言，并在失败时抛出带上下文信息的 `AssertionError`。
- 方法名直述预期（如 `assertOrderStatusIsConfirmed(order)` 而非 `assertEquals("CONFIRMED", order.getStatus())`）
- 参数尽量少而明确，避免传入冗余字段
- 失败消息中包含实际值、期望值和业务上下文，便于快速定位
示例：
public class OrderAssertions {
public static void assertOrderStatusIsConfirmed(Order order) {
if (!"CONFIRMED".equals(order.getStatus())) {
throw new AssertionError(
String.format("Expected order %s status to be CONFIRMED, but was %s",
order.getId(), order.getStatus())
);
}
}
}
组合已有断言并增强错误信息
不必重复造轮子，可复用 `org.junit.jupiter.api.Assertions` 的方法，在其基础上包装语义逻辑。
立即学习“Java免费学习笔记（深入）”；
- 用 `Assertions.assertEquals(expected, actual, messageSupplier)` 提供动态失败消息
- 对集合、对象状态等复杂判断，先做预处理再断言（如提取关键字段、计算衍生值）
- 避免在断言方法里做副作用操作（如修改对象、发起网络请求）
示例：
public static void assertPaymentAmountMatchesOrder(Payment payment, Order order) {
BigDecimal expected = order.getTotalAmount().multiply(BigDecimal.valueOf(1.05)); // 含税
Assertions.assertEquals(expected, payment.getAmount(),
() -> String.format("Payment amount mismatch for order %s: expected %s (with tax), got %s",
order.getId(), expected, payment.getAmount())
);
}
使用 AssertJ 实现链式语义断言（推荐）
AssertJ 是事实标准的流式断言库，比手写工具类更强大、更易维护。引入依赖后，可写出类似 `assertThat(order).hasStatus("CONFIRMED").hasItemsCount(3)` 的代码。
- 添加 Maven 依赖：
org.assertj:assertj-core - 为业务类型写自定义 `AbstractAssert` 子类（如 `OrderAssert`），重写 `isConfirmed()` 等方法
- 提供静态工厂方法（如 `OrderAssert.assertThat(order)`）方便调用
示例片段：
public class OrderAssert extends AbstractAssert<OrderAssert, Order> {
public OrderAssert(Order order) {
super(order, OrderAssert.class);
}
public static OrderAssert assertThat(Order order) {
return new OrderAssert(order);
}
public OrderAssert isConfirmed() {
isNotNull();
if (!"CONFIRMED".equals(actual.getStatus())) {
failWithMessage("Expected order to be CONFIRMED but was <%s>", actual.getStatus());
}
return this;
}
}
配合测试数据构建器提升整体可读性
自定义断言效果最大化，需搭配语义化的测试数据构造方式。例如用 `OrderBuilder.confirmed().withItems(2)` 创建待测对象，再接 `assertThat(...).isConfirmed()`，整行测试即是一句完整业务断言。
- 避免在测试方法体内拼接对象字段，把构造逻辑下沉到 Builder 或 Factory 类
- Builder 方法名体现业务状态（如 `.asRefunded()`、`.withPendingItems()`）
- 断言与构造形成语义闭环：“我建了一个已确认订单，它应该状态是 CONFIRMED”
