JUnit 5中“断言消息可延迟求值”含义？何时必须用Lambda？

一、什么是“断言消息延迟求值”？ #

直接传字符串作为断言消息时，不管断言成功还是失败，这个字符串都会提前生成——哪怕断言逻辑完全正确，字符串拼接、动态计算这些操作也会白跑一遍。

而用() -> "..."这种Lambda形式时，消息的生成会被推迟：只有当断言失败的时候，Lambda里的代码才会执行，生成对应的错误消息。这就是所谓的“延迟求值”——把消息生成的动作推迟到真正需要它的时刻。

二、示例对比看差异 #

1. 直接传字符串的冗余开销 #

@Test
void testDirectString() {
    // 不管1+1是不是等于2，这个字符串拼接都会先执行
    assertEquals(2, 1 + 1, "计算错误：预期2，实际得到" + (1 + 1));
}

哪怕断言成功，"计算错误：预期2，实际得到" + (1 + 1)这段拼接代码也会运行，做了无意义的工作。

2. Lambda形式的高效执行 #

@Test
void testLambdaMessage() {
    // 只有当1+1不等于2时，才会执行Lambda里的字符串拼接
    assertEquals(2, 1 + 1, () -> "计算错误：预期2，实际得到" + (1 + 1));
}

如果断言成功，Lambda里的代码完全不会触发，节省了不必要的计算资源。

三、哪些场景必须用Lambda？ #

• 消息生成开销大的场景：比如需要调用耗时方法（查数据库、读取大日志文件、复杂数据格式化）生成错误消息时，直接传字符串会每次都执行这些耗时操作，用Lambda能避免断言成功时的无效消耗。

  @Test
  void testExpensiveMessage() {
      // 假设getUserDebugInfo()是个耗时方法，只有断言失败才会调用它
      assertTrue(user.isVerified(), () -> "用户未验证，详情：" + getUserDebugInfo(user.getId()));
  }
  

• 消息生成可能抛出异常的场景：如果生成消息的代码本身可能抛出异常，直接传字符串会在断言执行前就触发异常，导致测试莫名失败（不是因为断言逻辑错了，而是消息生成出错）；用Lambda的话，只有断言失败时才会执行这段代码，不会影响正常的断言成功流程。

  @Test
  void testMessageWithExceptionRisk() {
      // 假设getUserDetails()在用户不存在时会抛异常，但这里断言用户不为null，正常情况不会执行Lambda
      assertNotNull(user, () -> "用户不存在，详情：" + getUserDetails(user.getId()));
  }
  

• 需要惰性加载资源的场景：比如从国际化配置文件、远程配置中心读取错误消息，用Lambda可以避免测试启动时就加载这些资源，减少初始化阶段的资源占用。

内容的提问来源于stack exchange，提问作者Manuel Jordan