LocalDateTime精度断言错误怎么解决

本文针对集成测试中LocalDateTime对象精度差异导致的断言失败问题，提出了一种有效的解决方案。由于数据库存储、JSON序列化等过程可能导致LocalDateTime精度丢失，直接比较字符串形式的时间戳容易出错。文章指出，关键在于避免直接的字符串比较，而是将从API响应中获取的时间字符串解析为LocalDateTime对象，并与期望值在统一精度下进行比较。通过自定义Hamcrest Matcher，可以实现对响应时间字符串的解析和精度控制，从而确保断言的准确性，有效解决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 默认支持纳秒级别的精度。然而，这种精度在整个数据流转过程中可能无法得到完全保留：

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

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

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

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

1. 定义自定义 Hamcrest Matcher

创建一个 LocalDateTimeStringMatcher，它能够接收一个 List（因为 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> {

    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 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

理论要掌握，实操不能落！以上关于《LocalDateTime精度断言错误怎么解决》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！