LocalDateTime 在集成测试中断言精度问题的解决之道-小浪学习网

LocalDateTime 在集成测试中断言精度问题的解决之道

本文探讨了在集成测试中，由于 LocalDateTime 对象在 toString() 格式与实际存储或 JSON 序列化后的精度差异导致的断言失败问题。核心解决方案是避免直接比较字符串，而是将从响应中获取的时间字符串解析回 LocalDateTime 对象，并确保与期望值在相同精度下进行比较，以确保断言的准确性。

问题描述：LocalDateTime 精度断言失败

在进行集成测试时，我们经常会遇到 LocalDateTime 相关的断言失败，尤其是在比较从 API 响应中获取的时间戳与测试代码中创建的时间戳时。典型的错误信息如下：

Java.lang.AssertionError: 1 expectation failed. json path _embedded.positionsSnapshotDToes.linkTime doesn't match. Expected: <[2022-11-09T10:01:03.152146400]>   Actual: [2022-11-09T10:01:03.152146]

从上述错误可以看出，期望值（Expected）的时间戳包含了纳秒（400），而实际值（Actual）的时间戳只精确到微秒，缺少了最后的纳秒部分。这表明在数据存储、传输或序列化过程中，LocalDateTime 的精度发生了变化。

问题的核心代码片段通常涉及 JPA 实体和 RestAssured 测试：

// JPA 实体中的 LocalDateTime 字段 @Column(name = "LINK_TIME") private LocalDateTime linkTime;  // 集成测试代码片段 @Test void shouldPasslinkTime() {     final LocalDateTime anyLinkTime = LocalDateTime.now(); // 包含纳秒精度      // 保存实体到数据库     posSnapshotRepo.save(             PositionsSnapshot.builder()                     .linkTime(anyLinkTime)                     .build()     );      // 调用 API 并断言     given()             .spec(correctCredentialsAndPortSpec)             .log().ifValidationFails()             .contentType("application/json")             .body(MAPPER_HELPER.writeValueAsString(dto))             .when()             .post("service/unmatched")             .then()             .statusCode(200)             .log().ifValidationFails()             .and().body("_embedded.positionsSnapshotDToes.linkTime", equalTo(Arrays.asList(anyLinkTime.toString()))) // 直接比较字符串             // ... 其他断言     }

在上述测试代码中，anyLinkTime 是通过 LocalDateTime.now() 创建的，通常会包含纳秒级别的精度。然而，当它经过 JPA 存储到数据库，再通过 REST API 响应序列化为 JSON 字符串时，其精度可能会被截断（例如，数据库列类型限制或 JSON 序列化器默认行为）。直接将 anyLinkTime.toString() （包含纳秒）与从 JSON 响应中获取的字符串（可能不含纳秒）进行比较，自然会导致断言失败。

问题根源分析

LocalDateTime 默认支持纳秒级别的精度。然而，这种精度在整个数据流转过程中可能无法得到完全保留：

LLaMA

Meta公司发布的下一代开源大型语言模型

179

查看详情

数据库精度限制： 并非所有数据库的日期时间类型都支持纳秒精度。例如，mysql 的 DATETIME 类型在 5.6.4 版本之前只支持到秒，之后才支持到微秒（DATETIME(6)）。SQL Server 的 datetime 类型只支持到毫秒，而 datetime2 支持到纳秒。如果数据库列的精度低于 LocalDateTime 的纳秒精度，那么在存储时就会发生截断。
JPA 映射： JPA 框架在将 LocalDateTime 映射到数据库时，会受到数据库列类型精度的影响。即使 LocalDateTime 对象具有纳秒，如果数据库列是 DATETIME(6)，则只会存储到微秒。
JSON 序列化/反序列化： JSON 库（如 Jackson）在将 LocalDateTime 对象序列化为字符串时，可能也有其默认的精度设置。同样，在反序列化时，如果字符串中缺少纳秒部分，它也无法恢复。
字符串比较的局限性： 直接比较 LocalDateTime 对象的 toString() 结果，实际上是在比较两个字符串。只要字符串内容有任何细微差别（如精度不同），即使它们代表的时间点在业务逻辑上是等价的，也会被认为是不同的。

解决方案：解析后比较 LocalDateTime 对象

解决此问题的核心思想是：确保在进行比较时，期望值和实际值都处于相同的类型和精度级别。 最健壮的方法是将从 API 响应中获取的时间字符串解析回 LocalDateTime 对象，并对两者进行统一的精度截断后再进行比较。

由于 RestAssured 的 body() 方法的第二个参数期望的是一个 Hamcrest Matcher，并且 JSON Path 表达式不能直接作为 LocalDateTime.parse() 的参数，我们需要创建一个自定义的 Hamcrest Matcher 来封装这个解析和比较的逻辑。

1. 定义自定义 Hamcrest Matcher

创建一个 LocalDateTimeStringMatcher，它能够接收一个 List<String>（因为 JSON Path _embedded.positionsSnapshotDToes.linkTime 返回的是一个列表），将其中的时间字符串解析为 LocalDateTime，并与我们期望的 LocalDateTime 对象在指定精度下进行比较。

 import org.hamcrest.Description; import org.hamcrest.TypeSafeMatcher;  import java.time.LocalDateTime; import java.time.temporal.ChronoUnit; import java.util.List;  public class LocalDateTimeStringMatcher extends TypeSafeMatcher<List<String>> {      private final LocalDateTime expectedDateTime;     private final ChronoUnit precisionUnit; // 定义比较精度      /**      * 构造函数      * @param expectedDateTime 期望的 LocalDateTime 对象      * @param precisionUnit 比较时使用的精度单位，例如 ChronoUnit.MICROS      */     public LocalDateTimeStringMatcher(LocalDateTime expectedDateTime, ChronoUnit precisionUnit) {         // 在构造时就对期望值进行截断，以匹配数据库/JSON的实际精度         this.expectedDateTime = expectedDateTime.truncatedTo(precisionUnit);         this.precisionUnit = precisionUnit;     }      @Override     protected boolean matchesSafely(List<String> item) {         if (item == null || item.isEmpty()) {             return false;         }         // 假设我们只关心列表中的第一个时间戳         String actualDateTimeString = item.get(0);         try {             // 将从响应中获取的字符串解析为 LocalDateTime             LocalDateTime actualDateTime = LocalDateTime.parse(actualDateTimeString);             // 对实际值也进行相同的精度截断，然后进行比较             return actualDateTime.truncatedTo(precisionUnit).equals(expectedDateTime);         } catch (java.time.format.DateTimeParseException e) {             // 处理解析异常，例如日志记录             System.err.println("Failed to parse date-time string: " + actualDateTimeString + " - " + e.getMessage());             return false;         }     }      @Override     public void describeTo(Description description) {         description.appendText("a list containing LocalDateTime matching (truncated to " + precision