アサートとJUnitアサーション

85

今日、JUnitアサーションの代わりにJavaアサーションを使用したJUnitテストケースを見ました。一方を他方よりも優先するという重大な長所または短所はありますか？

— ロバート
ソース

JUnitアサーションとJavaの「assert」キーワードの間には絶対に事実上の違いがあります。これは、意見に基づく質問ではありません。

— トーマス

95

JUnit4では、JUnitアサートによってスローされる例外（実際にはError）は、javaassertキーワード（AssertionError）によってスローされるエラーと同じであるためassertTrue、スタックトレース以外はまったく同じであり、違いはわかりません。

そうは言っても、アサートはJVMで特別なフラグを使用して実行する必要があり、JUnitテストの実行時に誰かがそのフラグを使用してシステムを構成するのを忘れたという理由だけで、多くのテストに合格したように見えます。

一般に、このため、JUnitを使用するassertTrue方が良い方法であるとassertThat主張します。これは、テストの実行が保証され、一貫性が保証され（Javaキーワードではない他のアサートを使用する場合もあります）、JUnitの動作がアサートするかどうかを保証するためです。将来変更された場合（ある種のフィルターや他の将来のJUnit機能へのフックなど）、コードはそれを活用できるようになります。

Javaのassertキーワードの本当の目的は、ランタイムペナルティなしでそれをオフにできるようにすることです。これは単体テストには適用されません。

— Yishai
ソース

26

JUnitアサーションは、組み込みassertステートメントよりも豊富なAPIを提供し、さらに重要なことにassert、-eaJVM引数を必要とするとは異なり、明示的に有効にする必要がないため、JUnitアサーションを好みます。

— アダムスキ
ソース

1

-eaで常に有効になりmvn test、の必要はありません-ea。より豊富なAPI、良いキャッチ。APIはアプリケーションの一部ではないため（APIのa）、テストで誤用されていると思うことがあります。私はそれをよりリッチなメソッドと呼ぶことを好みます。

— グリム

20

テストが失敗すると、より多くの情報が得られます。

assertEquals(1, 2); 結果は java.lang.AssertionError: expected:<1> but was:<2>

vs

assert(1 == 2); 結果は java.lang.AssertionError

メッセージ引数をに追加すると、さらに多くの情報を取得できます assertEquals

— スターマー
ソース

9

試してみてくださいassert 1==2: "1 is not 2";。

— グリム

@PeterRader -eaが有効になっていない場合は、assertキーワードを試してください。または、常に機能するJUnitアサーションを使用することをお勧めします。

— トーマス

1

@ThomasW -eaが有効になっていない場合、テストではありません。JUnitアセレーションは常に機能するとは限りません。フレームワークであるJUnitを使用する場合にのみ機能します。また、Maven依存関係の場合は、テストスコープ内にのみ存在する必要があるMaven依存関係です。ここには2つの側面があります。何が好きですか。1番目の側面：ダウンロードする必要がある、test-scopeのみの依存関係としてフレームワークを使用します。このフレームワークを使用すると、src / main-folderにはないが、mavenにはtest-にのみjunitがあるため、そこでコンパイルされないクラスで使用できます。スコープまたはセカンドサイド：組み込みのものを使用します。

— グリム

1

@PeterRaderこの質問は、JUnitテストケースに関するものです。そのコンテキストでは、JUnitまたは同様のアサーションクラスを使用する必要があります。これらは常に有効になっているためです。私は個人的に、Javaの「assert」キーワードが過去に有効になっていないことに気づきました。信頼できないアサーションがテストコードに含まれているとは思いません。

— トーマス

機能コードのアサーションとは別のコンテキストで（堅牢なプログラミングの実践にとって重要ですが、実際には問題のトピックではありません）、SpringとGoogleGuavaの両方に常に有効になっているアサーションクラスがあります。正確性を確保するために、パラメーターと状態の前提条件としてこれらを惜しみなく使用することをお勧めします。それ以外にも、パフォーマンスが重要な地域で、Javaは小さな領域があることができassert正しさを確認するために-が好ましいかもしれないでしょうパフォーマンスに影響を与えるので、最高のデフォルトでは無効になっています。ただし、私の経験では、ほとんどのアサーションは常にオンになっている必要があります。

— トーマス

8

テストケースではJUnitアサーションを使用し、コードではjavaのアサーションを使用すると思います。言い換えれば、実際のコードは、明らかなようにJUnitの依存関係を持つことはなく、テストの場合は、アサートではなく、そのJUnitのバリエーションを使用する必要があります。

— ブルーノD.ロドリゲス
ソース

0

JUnitを使用している場合は、JUnitアサーションを使用する必要があります。assertTrue()基本的にはと同じですがassert、それ以外の場合はなぜJUnitを使用するのですか？

— CheesePls
ソース

4

テスト実行フレームワークにはJUnitを使用します。アサートは、JUnitが提供する価値のほんの一部です。JUnitがないAssertと、より多くのボイラープレートが必要になります。assertJUnitがないと、フレームワーク全体を作成する必要があります。

— Yishai 2010年

1

ツールを使用する場合は、ツールを使用してください。通常の古いassertステートメントは、JUnitテストケースでは少しばかげているように見えます。私の意見では、それらは実際のコードに属しています。

— cheesePls 2010年

1

@CheesePlsの「通常の古いassertステートメント」は、実際にはJUnitがアサートするよりも新しいものです。

— ドルメン2012

0

光沢のある新しいものだけを使用する場合、これは当てはまらない可能性がありますが、assertは1.4SEまでJavaに導入されませんでした。したがって、古いテクノロジーを使用する環境で作業する必要がある場合は、互換性の理由からJUnitに頼ることができます。

— ダンコーツ
ソース