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 
} 

だから、なぜでしょうか？ b == iがtrueなので、値は明らかにJVMで等しいので、hamcrestはなぜ失敗しますか？

Answer 1

Assert#assertThatは一般的な方法です。プリミティブ型はジェネリックでは機能しません。この場合、byteとintはそれぞれByteとIntegerに囲まれています。

引数がそうでない場合は、直ちにfalseを返す、タイプByteである場合には、次に（assertThat内）

Byte b = 0; 
Integer i = 0; 

b.equals(i); 

Byte#equals(Object)の実装チェックなります。一方

、assertEquals両方byteとint引数がlong値に昇格された場合にAssert#assertEquals(long, long)あります。内部的には、これは等しい2つのプリミティブlong値に対して==を使用します。 assertThatはbyteがTためByteに箱詰めさ

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

として宣言されているので、このボクシング変換が動作し、intがへの呼び出し内（Integerに箱詰めされていることを

---

注equalTo）が、として、Matcher<? super T>に一致すると推測されます。

これはJava 8の改良された汎用推論で機能します。あなたはそれがhamcrestのマッチャーは、オブジェクト上ではなく、プリミティブで動作するようintとbyteがIntegerとByteに箱詰めされているので、これが起こる

Answer 2

のJava 7で動作するように明示的な型の引数を必要とするだろう。だから、ByteとIntegerを比較している、とByte.equals()の実装は次のとおりです。

public boolean equals(Object obj) { 
    if (obj instanceof Byte) { 
     return value == ((Byte)obj).byteValue(); 
    } 
    return false; 
} 

とInteger.equals()：

つまり

public boolean equals(Object obj) { 
    if (obj instanceof Integer) { 
     return value == ((Integer)obj).intValue(); 
    } 
    return false; 
} 

、IntegerとByteは常に等しくありません。プリミティブを比較する場合は、代わりにAssert.assertEqualsを使用してください。 hamcrest matcherは強力ですが、主に（複雑な）オブジェクトアサーションを対象としています。