LocalDateTime 集成测试中时间精度不匹配问题的解决方案

第一段引用上面的摘要：

本文旨在解决 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 对象的值，而不是字符串的格式。

修改后的测试代码如下：

AI-Text-Classifier

OpenAI官方出品，可以区分人工智能书写的文本和人类书写的文本

59

查看详情

@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可以更灵活地处理复杂的断言逻辑。

以上就是LocalDateTime 集成测试中时间精度不匹配问题的解决方案的详细内容，更多请关注php中文网其它相关文章！