JUnit-間違ったアサートの使用

Question

exuberoのエントリからこの投稿を引用します。このエントリは、単体テストを行うすべての人に役立つと思います：

JunitのAssertクラスで定義されたassertで始まる多くの異なるメソッドがあります。これらの各メソッドには、主張する内容に関する引数とセマンティクスがわずかに異なります。

以下にassertTrueの不規則な使用例を示します。

assertTrue("Objects must be the same", expected == actual);
assertTrue("Objects must be equal", expected.equals(actual));
assertTrue("Object must be null", actual == null);
assertTrue("Object must not be null", actual != null);

ユニットテストの専門家の中には、上記のコードは次のように記述した方が良いと指摘しました。

assertSame("Objects must be the same", expected, actual);
assertEquals("Objects must be equal", expected, actual);
assertNull("Object must be null", actual);
assertNotNull("Object must not be null", actual);

適切な「assertXXX（）」を使用する利点の1つは、単体テストの可読性を向上させることです。適切な 'assertXXX（）'を使用することのその他の利点を誰でも指摘できますか？

Answer 1

私はJava開発者ではなく、アサーションが失敗したときにJUnitが出力するものがわかりません。 私が使用してきた多くの単体テストフレームワークは、assertEqualsのようなものを使用すると、より良いエラー情報を出力します。

私が話している例を紹介しましょう：

assertTrue("Objects must be equal", "One" == "Two");
assertEquals("Objects must be equal", "One", "Two");

最初のケースでは、次のようなエラー出力が得られます。

エラー：期待されるtrue actualはfalseです。

2番目の場合の出力：

エラー：実行済み＆quot; One＆quot;実際は「2」でした。

おわかりのように、2番目のケースはより有意義な情報を提供します。

Answer 2

上記の@Vadimが提案したものに加えて、適切なアサートを使用すると、テストのカットコピーペーストによって作成されるバグを防ぐことができます。

例として

assertTrue("Objects must not be the same", expected != actual);

次にコピーおよび変更された

assertTrue("Objects must not be the same", newobject == actual);

コードが変更され、このテストが失敗し、コメントが次の開発者をだまして「修正」した場合新しいバグを導入する方法でコードを作成します。

cut-copy-paste-codeが次のような場合：

assertFalse("Objects must be the same", newobject == actual);

コメント、アサーション、およびテストケースの不一致がより顕著になる場合があります。

そして、はい、私はこれが起こるのを見ました。