【发布时间】:2021-08-19 08:11:06
【问题描述】:
我目前正在将一些项目从 Java 8 升级到 Java 11,其中一个转换器的单元测试失败了。基本上,问题源于由于之前通过 JDK 8 传递的日期精度而导致相等性检查失败。
这是测试的部分示例,为了清楚起见,我移动了转换器的内容:
@Test
public void testDateTime() {
LocalDateTime expected = LocalDateTime.now().plusDays(1L);
// converter contents
long epochMillis = expected.atZone(ZoneId.systemDefault())
.toInstant().toEpochMilli();
LocalDateTime actual = LocalDateTime.ofInstant(Instant.ofEpochMilli(epochMillis),
TimeZone.getDefault().toZoneId());
assertThat(actual, equalTo(expected));
}
这会导致资产错误,原因是:
Expected :<2021-06-02T14:06:21.820299>
Actual :<2021-06-02T14:06:21.820>
我可以用assertThat(actual, equalTo(expected.truncatedTo(ChronoUnit.MILLIS))) 对预期进行中继以使它们相等,但是,这意味着每次与正在测试的转换器类进行比较(isAfter、isBefore、等于)时,都必须应用中继。
对于 JDK 11(或者我可能错过的文档 :)),是否有适当的方法在 LocalDateTime 和 Long 之间进行转换?
更新:
正如 cmets 中所指出的,Java 8 和 11 的表示方式不同,因此导致测试失败。为了提供更多关于这篇文章所要求的内容,这里有两种方法正在被测试验证(我移动到测试本身只捕获正在执行的内容,因为失败的单元测试属于使用的类实用方法)
public Long localDateTimeToEpochMillis(LocalDateTime ldt) {
Instant instant = ldt.atZone(ZoneId.systemDefault()).toInstant();
return ldt.atZone(ZoneId.systemDefault())
.toInstant().toEpochMilli();
}
和
public LocalDateTime epochMillisToLocalDateTime(long epochMillis) {
return LocalDateTime.ofInstant(
Instant.ofEpochMilli(epochMillis),
ZoneId.systemDefault());
}
现有测试似乎验证的是,给定一个 long 值,我应该得到相同的 LocalDateTime 等效值,这是通过使用 Given(LocalDateTime 转换为 Long 值)然后返回 LocalDateTime 进行比较来完成的。
【问题讨论】:
-
您是否尝试过 Instant.ofEpochSecond 并将 Instant.getNano() 作为第二个参数传递?或者最好只使用 Instant 而不是毫秒和纳秒。
-
我相信这个问题更多地围绕着 Java-8 和 Java-11 之间的期望不匹配。但为此,您可能需要说明当前测试所依赖的假设或文档。
-
不幸的是我不能,有些情况下需要长值(即与protobuf相关的转换等)。另一方面,使用 nanoAdjustment 作为 ofEpochSecond 的第二个参数是可行的。
-
你还没有解释这实际上应该测试什么。因此我们无法告诉您您的测试代码是否正确。
-
顺便说一句,我无法想象在任何情况下调用
LocalDateTime.now是正确的做法。该类故意缺少时区的上下文或与 UTC 的偏移量,因此它不能代表一个时刻,它不是时间线上的特定点。Instant.now()应该用于捕捉当前时刻。
标签: java java-8 java-11 localdatetime