Java TDD：利用AssertionError记录关键变量断言失败

在测试驱动开发（TDD）实践中，直接抛出AssertionError来“记录”测试失败是一个常见误区。实际上，AssertionError是断言失败时由JVM自动抛出的异常，并非记录工具。关键在于让测试失败报告本身成为清晰的诊断书，自动揭示关键变量状态，从而快速定位问题根源。

避免直接抛出 AssertionError，使用 JUnit 断言方法

Ja va原生的assert语句在默认配置下禁用，且错误信息简陋。在TDD中，应依赖JUnit（5及以上版本）等成熟测试框架，它们提供语义化的断言方法，失败时会自动生成包含关键信息的报告：

• assertEquals(expected, actual)：断言失败时自动打印expected（期望值）和actual（实际值）的具体内容。
• assertTrue(condition, “msg”)：支持自定义失败消息，可将变量值拼接进去，例如：assertTrue(list.size() == 3, “Expected size 3, but got ” + list.size())。
• JUnit 5的assertAll()：允许批量执行多个断言。即使某个失败，也会继续执行其余断言，最后汇总所有失败结果，一次性展示多个变量状态。

在失败消息中显式暴露关键变量值

清晰的失败信息有助于高效调试。应避免空泛断言，将参与逻辑判断的核心变量值直接写入断言消息。对比以下做法：

• 低效做法：assertNotNull(result); —— 测试失败时仅知result为null，不知其本应为何值或产生条件。
• 推荐做法：assertNotNull(result, “User creation failed: returned null for input name='” + name + “‘”); —— 失败消息直接表明在创建用户且输入特定名称时返回了null。
• 更优做法（JUnit 5）：使用Lambda表达式延迟消息求值，避免断言通过时无谓的字符串拼接，提升性能：assertEquals(42, computedValue, () -> “Unexpected value when processing id=” + userId + “, config=” + config.toString());

配合日志或调试器，在断言前主动观察变量

AssertionError是测试失败的“结果”，而非观察中间过程的“手段”。在TDD“红-绿-重构”循环中，若逻辑复杂，可在编写测试代码时临时插入观测点：

• 打印关键中间值：在断言语句前使用System.out.println(“debug: user.age=” + user.getAge() + “, threshold=” + MIN_AGE);，运行测试时可在控制台查看这些值。
• 使用IDE条件断点：在调试模式下运行测试，在可能出问题的变量访问处（如user.getAge()）设置条件断点，直接查看调用栈帧中的所有变量状态。
• 用断言包裹可疑逻辑：对可能抛出异常的逻辑，使用Assertions.assertDoesNotThrow()进行包裹。若异常发生，可在测试框架报告帮助下结合上下文分析。

自定义断言工具类封装常用逻辑与变量输出

当项目中特定校验逻辑高频出现时（如金额精度对比、时间范围校验），可封装自定义断言工具方法。这能统一错误报告格式，并方便复用上下文信息。

• public static void assertMoneyEquals(BigDecimal expected, BigDecimal actual, String context) {
    String msg = String.format(“Money mismatch in %s: expected %s, got %s”, context, expected, actual);
    assertEquals(expected, actual, msg);
  }

• 调用示例：assertMoneyEquals(new BigDecimal(“19.99”), order.getTotal(), “checkout step”);
• 好处：代码更简洁，诊断信息格式统一且包含业务上下文（如“checkout step”）。未来如需增强诊断逻辑（如记录更多环境变量），仅需在一处修改。