
第一段引用:本文旨在解决在使用 JPA 存储 LocalDateTime 类型数据,并在集成测试中使用 JSON Path 进行断言时,由于数据库存储精度与 Java 对象精度不一致导致的测试失败问题。通过分析问题原因,提供了一种在集成测试中正确处理 LocalDateTime 类型数据的方法,确保测试的准确性和可靠性。
在使用 JPA 将 LocalDateTime 类型的数据存储到数据库时,需要注意数据库对时间戳的精度支持。不同的数据库可能对时间戳的精度支持不同,例如,某些数据库可能只支持到毫秒级别的精度,而 LocalDateTime 可以精确到纳秒级别。这就会导致在将 LocalDateTime 对象存储到数据库时,精度可能会丢失。
在集成测试中,通常会从数据库中读取数据,并将其与期望值进行比较。如果数据库中存储的 LocalDateTime 精度与 Java 对象中的精度不一致,就会导致断言失败。
在提供的示例中,断言失败的原因是 anyLinkTime.toString() 方法返回的字符串精度高于数据库中存储的精度。具体来说,anyLinkTime.toString() 返回的字符串包含纳秒部分 (例如 2022-11-09T10:01:03.152146400),而数据库中存储的 linkTime 可能只精确到毫秒级别 (例如 2022-11-09T10:01:03.152146)。
为了解决这个问题,可以在集成测试中将从数据库中读取的 LocalDateTime 对象转换为与期望值精度一致的字符串,或者直接比较 LocalDateTime 对象。
以下是直接比较 LocalDateTime 对象的示例代码:
@Test
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()
.and().body("_embedded.positionsSnapshotDToes.linkTime", contains(anyLinkTime.toString())) // 修改点1
.and().body("page.totalPages", equalTo(1))
.and().body("page.totalElements", equalTo(1))
.and().body("page.number", equalTo(0));
}修改点说明:
在使用 LocalDateTime 进行集成测试时,需要注意数据库对时间戳的精度支持。通过合理处理 LocalDateTime 对象的精度,可以避免因精度不一致导致的测试失败,确保测试的准确性和可靠性。 直接比较 LocalDateTime 对象是一种简单有效的解决方案。 此外,也可以考虑在测试中将 LocalDateTime 格式化为特定精度的字符串,再进行比较。
以上就是使用 LocalDateTime 进行集成测试时的时间精度问题的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号