LocalDateTime时间精度测试与解决方法

本文旨在解决LocalDateTime在集成测试中因数据库存储精度与JSON响应精度不一致而导致的断言错误问题。针对JPA存储LocalDateTime对象后，API接口返回的时间精度可能低于数据库存储精度（例如纳秒级与微秒级差异）的问题，提出解决方案：通过LocalDateTime.parse()方法解析API响应中的时间字符串，将其转换为LocalDateTime对象，再与期望值进行比较。修改后的测试代码示例展示了如何利用Groovy Closure处理断言，确保测试的准确性。同时提醒开发者注意API返回的时间字符串格式，必要时使用DateTimeFormatter指定格式。掌握此方法，可有效避免因时间精度问题导致的集成测试失败，提升测试质量和效率。

第一段引用上面的摘要：

本文旨在解决 LocalDateTime 集成测试中，数据库存储的时间精度与 JSON 响应中的时间精度不一致导致的断言错误问题。通过分析问题原因，并提供修改后的测试代码，帮助读者理解如何在集成测试中正确处理 LocalDateTime 类型的数据，确保测试的准确性和可靠性。

问题分析

在集成测试中，当使用 JPA 将 LocalDateTime 对象存储到数据库，然后通过 API 接口返回时，可能会遇到时间精度不匹配的问题。例如，数据库中存储的时间精度为纳秒级别（例如：2022-11-09T10:01:03.152146400），而 API 响应中返回的时间精度可能只到微秒级别（例如：2022-11-09T10:01:03.152146）。这会导致集成测试中的断言失败，因为期望的值与实际的值不完全一致。

在提供的示例代码中，断言失败的原因就是 anyLinkTime.toString() 方法返回的字符串格式与 API 响应中的时间格式不一致。anyLinkTime.toString() 默认会保留纳秒精度，而 API 响应可能进行了截断。

解决方案

为了解决这个问题，需要在断言时对 API 响应中的时间字符串进行解析，将其转换为 LocalDateTime 对象，然后再进行比较。这样可以确保比较的是 LocalDateTime 对象的值，而不是字符串的格式。

修改后的测试代码如下：

@Test
void shouldPassLinkTime() {

    final LocalDateTime anyLinkTime = LocalDateTime.now();

    posSnapshotRepo.save(
            PositionsSnapshot.builder()
                    .linkTime(anyLinkTime)
                    .build()
    );

    SnapshotFilterDTO dto = SnapshotFilterDTO.builder()
            .build();

    given()
            .spec(correctCredentialsAndPortSpec)
            .log().ifValidationFails()
            .contentType("application/json")
            .body(MAPPER_HELPER.writeValueAsString(dto))
            .when()
            .post("service/unmatched")
            .then()
            .statusCode(200)
            .log().ifValidationFails()
            // 使用 LocalDateTime.parse 解析 API 响应中的时间字符串
            .and().body("_embedded.positionsSnapshotDToes.linkTime[0]", (response) -> {
                String linkTimeStr = response.asString();
                LocalDateTime actualLinkTime = LocalDateTime.parse(linkTimeStr);
                assertThat(actualLinkTime).isEqualTo(anyLinkTime);
            })

            .and().body("page.totalPages", equalTo(1))
            .and().body("page.totalElements", equalTo(1))
            .and().body("page.number", equalTo(0));
}

代码解释:

1. _embedded.positionsSnapshotDToes.linkTime[0]: 指定要断言的 JSON 数组中的第一个元素。假设API返回的linkTime是一个包含一个LocalDateTime字符串的数组。
2. (response) -> { ... }: 使用 Groovy Closure 来处理断言。response 对象包含了 _embedded.positionsSnapshotDToes.linkTime[0] 对应的值。
3. String linkTimeStr = response.asString();: 将响应值转换为字符串。
4. LocalDateTime actualLinkTime = LocalDateTime.parse(linkTimeStr);: 使用 LocalDateTime.parse() 方法将字符串解析为 LocalDateTime 对象。 这里假设 API 返回的时间字符串格式是 LocalDateTime.parse() 可以处理的默认格式。如果 API 返回的格式不同，需要使用 DateTimeFormatter 指定格式。
5. assertThat(actualLinkTime).isEqualTo(anyLinkTime);: 使用 assertThat 进行断言，比较解析后的 LocalDateTime 对象与期望的 LocalDateTime 对象是否相等。

注意事项:

• 确保 API 响应中的时间字符串格式与 LocalDateTime.parse() 方法能够解析的格式一致。如果格式不一致，需要使用 DateTimeFormatter 指定格式。例如：

  DateTimeFormatter formatter = DateTimeFormatter.ISO_DATE_TIME;
  LocalDateTime actualLinkTime = LocalDateTime.parse(linkTimeStr, formatter);

• 如果API返回的linkTime是一个包含多个LocalDateTime字符串的数组，需要遍历数组，对每个元素进行解析和断言。

总结

在集成测试中处理 LocalDateTime 类型的数据时，需要注意数据库存储的时间精度与 API 响应中的时间精度是否一致。如果不一致，需要对 API 响应中的时间字符串进行解析，将其转换为 LocalDateTime 对象，然后再进行比较。这样可以确保测试的准确性和可靠性。 使用Groovy Closure可以更灵活地处理复杂的断言逻辑。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~