Deprecated: imwpcache\f884414bce24ee67f\f73723ec7b1919fa5::__construct(): Implicitly marking parameter $YECBGYFECGEAFWHA as nullable is deprecated, the explicit nullable type must be used instead in /www/wwwroot/www.chuangxiangniao.com/wp-content/plugins/imwpcache-dist/build/f884414bce24ee67ff73723ec7b1919fa5.php on line 2

Deprecated: imwpcache\f884414bce24ee67f\f73723ec7b1919fa5::__construct(): Implicitly marking parameter $BBWFDDBHHYHDXXAB as nullable is deprecated, the explicit nullable type must be used instead in /www/wwwroot/www.chuangxiangniao.com/wp-content/plugins/imwpcache-dist/build/f884414bce24ee67ff73723ec7b1919fa5.php on line 2
LocalDateTime 在集成测试中断言精度问题的解决之道_创想鸟

LocalDateTime 在集成测试中断言精度问题的解决之道

localdatetime 在集成测试中断言精度问题的解决之道

本文探讨了在集成测试中,由于 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

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
该如何进大厂做产品经理
上一篇 2025年11月14日 23:32:21
产品经理找工作现状如何
下一篇 2025年11月14日 23:32:26

相关推荐

发表回复

登录后才能评论
关注微信