Assert class JavaDoc の例を見ると
assertThat("Help! Integers don't work", 0, is(1)); // fails:
// failure message:
// Help! Integers don't work
// expected: is <1>
// got value: <0>
assertThat("Zero is one", 0, is(not(1))) // passes
私は大きな利点を見ていませんassertEquals( 0, 1 ).
コンストラクトがより複雑になった場合、メッセージにとっては良いことかもしれませんが、より多くの利点が見られますか? 読みやすさ？
assertFoo意図と完全に一致する が存在する場合には、大きな利点はありません。そのような場合、それらはほとんど同じように動作します。
しかし、もう少し複雑なチェックになると、利点がより明確になります。
val foo = List.of("someValue");
assertTrue(foo.contains("someValue") && foo.contains("anotherValue"));
Expected: is <true>
but: was <false>
対。
val foo = List.of("someValue");
assertThat(foo, containsInAnyOrder("someValue", "anotherValue"));
Expected: iterable with items ["someValue", "anotherValue"] in any order
but: no item matches: "anotherValue" in ["someValue"]
どちらが読みやすいかについて議論することはできますが、アサートが失敗すると、 から適切なエラー メッセージが表示されますが、 からassertThatはごくわずかな情報しか得られませんassertTrue。
バージョン 4.4 (導入された場所)の JUnitリリース ノートには、次の 4 つの利点が記載されています。
- 読みやすく、入力しやすい: この構文を使用すると、動詞、目的語、主語を使用するassertEquals ("equals 3 x" をアサート) ではなく、主語、動詞、目的語 ("x is 3" をアサート) の観点から考えることができます。
- 組み合わせ: 任意のマッチャー ステートメントを否定 ( not(s) )、組み合わせ ( either(s).or(t) )、コレクションにマップ ( each(s) )、またはカスタムの組み合わせ ( afterFiveSeconds(s) )で使用できます。 )
- 読み取り可能な失敗メッセージ。(...)
- カスタムマッチャー。Matcherインターフェースを自分で実装することにより、独自のカスタム アサーションで上記の利点をすべて得ることができます。
新しい構文を作成した人からのより詳細な議論: here .
基本的にコードの可読性を高めるため。
hamcrest の他に、fest アサーションも使用できます。それらには、ハムクレストに比べて次のようないくつかの利点があります。
assertEquals(123, actual); // reads "assert equals 123 is actual"対assertThat(actual).isEqualTo(123); // reads "assert that actual is equal to 123")import static org.fest.assertions.api.Assertions.*;
// common assertions
assertThat(yoda).isInstanceOf(Jedi.class);
assertThat(frodo.getName()).isEqualTo("Frodo");
assertThat(frodo).isNotEqualTo(sauron);
assertThat(frodo).isIn(fellowshipOfTheRing);
assertThat(sauron).isNotIn(fellowshipOfTheRing);
// String specific assertions
assertThat(frodo.getName()).startsWith("Fro").endsWith("do")
.isEqualToIgnoringCase("frodo");
// collection specific assertions
assertThat(fellowshipOfTheRing).hasSize(9)
.contains(frodo, sam)
.excludes(sauron);
// map specific assertions (One ring and elves ring bearers initialized before)
assertThat(ringBearers).hasSize(4)
.includes(entry(Ring.oneRing, frodo), entry(Ring.nenya, galadriel))
.excludes(entry(Ring.oneRing, aragorn));
Fest はもうアクティブではありません。代わりにAssertJを使用してください。
非常に基本的な正当化は、新しい構文を台無しにするのは難しいということです。
テスト後に特定の値 foo が 1 になるとします。
assertEqual(1, foo);
- また -
assertThat(foo, is(1));
最初のアプローチでは、正しい順序を忘れて逆に入力するのは非常に簡単です。その場合、1 を予期して 2 を取得したためにテストが失敗したと言うのではなく、メッセージは逆です。テストに合格した場合は問題ありませんが、テストに失敗した場合は混乱を招く可能性があります。
2 番目のバージョンでは、この間違いを犯すことはほとんど不可能です。
例：
assertThat(5 , allOf(greaterThan(1),lessThan(3)));
// java.lang.AssertionError:
// Expected: (a value greater than <1> and a value less than <3>)
// got: <5>
assertTrue("Number not between 1 and 3!", 1 < 5 && 5 < 3);
// java.lang.AssertionError: Number not between 1 and 3!
ところで：あなたもassertXXXでテキストを書くことができます...