本文探讨了在集成测试中，由于 LocalDateTime 对象在 toString() 格式与实际存储或 JSON 序列化后的精度差异导致的断言失败问题。核心解决方案是避免直接比较字符串，而是将从响应中获取的时间字符串解析回 LocalDateTime 对象，并确保与期望值在相同精度下进行比较，以确保断言的准确性。
问题描述：LocalDateTime 精度断言失败
在进行集成测试时，我们经常会遇到 LocalDateTime 相关的断言失败，尤其是在比较从 API 响应中获取的时间戳与测试代码中创建的时间戳时。典型的错误信息如下：
java.lang.AssertionError: 1 expectation failed.JSON path _embedded.positionsSnapshotDToes.linkTime doesn't match.Expected: Actual: [2022-11-09T10:01:03.152146]
从上述错误可以看出，期望值（Expected）的时间戳包含了纳秒（400），而实际值（Actual）的时间戳只精确到微秒，缺少了最后的纳秒部分。这表明在数据存储、传输或序列化过程中，LocalDateTime 的精度发生了变化。
问题的核心代码片段通常涉及 JPA 实体和 RestAssured 测试：
// JPA 实体中的 LocalDateTime 字段@Column(name = "LINK_TIME")private LocalDateTime linkTime;// 集成测试代码片段@Testvoid 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 默认支持纳秒级别的精度。然而，这种精度在整个数据流转过程中可能无法得到完全保留：
数据库精度限制： 并非所有数据库的日期时间类型都支持纳秒精度。例如，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（因为 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> { 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 在集成测试中断言精度问题的解决之道的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/77782.html
微信扫一扫 
支付宝扫一扫 
