java - 为什么 hamcrest 说字节 0 不等于 int 0？

Question

考虑以下使用标准 JUnit 断言和 hamcrest 的 assertThat 的测试用例:

byte b = 0;
int i = 0;

assertEquals(b, i); // success
assertThat(b, equalTo(i)); // java.lang.AssertionError: Expected: <0> but: was <0>

if (b == i) {
    fail(); // test fails, so b == i is true for the JVM
}

为什么会这样？对于 JVM，这些值显然是相等的，因为 b == i 是 true，那么为什么 hamcrest 会失败？

Answer 1

Assert#assertThat 是一种通用方法。原始类型不适用于泛型。在这种情况下，byte和 int被装箱到 Byte和 Integer ， 分别。

然后变成(在 assertThat 内)

Byte b = 0;
Integer i = 0;

b.equals(i);

Byte#equals(Object) 的实现检查参数是否为 Byte 类型, 返回 false如果不是，请立即。

另一方面，assertEquals是 Assert#assertEquals(long, long) 在这种情况下，byte和 int参数被提升为 long值(value)观。在内部，这使用 ==关于两个原始 long值相等。

---

请注意，此装箱转换有效，因为 assertThat被声明为

public static <T> void assertThat(T actual, Matcher<? super T> matcher) {

byte 在哪里被装箱到 Byte对于 T ，以及 int是盒装到 Integer (在对 equalTo 的调用中)，但推断为 Number匹配 Matcher<? super T> .

这适用于 Java 8 改进的通用推理。您需要显式类型参数才能使其在 Java 7 中工作。