JUnitテストでAssertionErrorを捕捉するのは良い考えですか？

Question

APIコールの結果としてオブジェクトがあり、メンバー変数の値をアサートする必要があります。

この値は、APIコールが最初に "見える"ものに応じて2つの期待値のいずれかになり、最初に設定されます。したがって、ある値のアサーションが失敗した場合は、そのテストを失敗として宣言する前に、別の値を宣言したいと思います。

これを行う最善の方法は何ですか？私が今持っていることは次のとおりです。

try { 
    assertEquals("message", someObject.getValue1(), expectedValue1); 
} catch(AssertionError ae) { 
    assertEquals("message", someObject.getValue1(), expectedValue2); 
} 

私は、これは許容練習である場合だけでわかりません。コメントしてください。

Answer 1

glorified goto文として例外を使用するのは、一般的には良い方法ではありません。あるいは、あなたは、あなたのキャリアの中で、プログラムのフロー制御のために例外を使用することについて曖昧な見方をする人々にぶつかるでしょう。

についてどのように：

Assert.assertTrue((someObject.getValue1().equals(expectedValue1) || (someObject.getValue2().equals(expectedValue2)); 

Answer 2

私は、このされていない良い習慣に関するAquilonのに同意します。

はしかし、あなたは他の前に一つの項目を「見る」APIをからかったり、「力」にはいくつかの他のメカニズムを使用できますか？そうすれば、あなたのテストはあるテストで真実であることを導く条件を反映することができ、別のテストでは他のアサーションが真実であることを反映することができます。

Answer 3

目的、自動化された機能テストまたはユニットテストに依存します。試験方法を失敗しlogbackロガーとJUnitのAssert.failを（）を使用しています。もちろん、

try { 
    assertTrue(boolean condition from earlier in test method to check); 
} 
catch(AssertionError uhOh) { 
    Logger.err("condition X failed: detailed info msg"); // broken item #1 

} 

try { 
    assertTrue(another condition in same method to check); 
} 
catch(AssertionError yuck) { 
    Logger.err("condition X failed: detailed info msg"); // another broken item 
    fail(); // now blow up as we've checked everything 
} 

：私は時々、元のためにこれを行います。この方法で、私は最初の後に爆発するのではなく、このメソッドのすべての失敗を知っています。私の場合は、リッチコンテンツのWebアプリケーション（多数のユーザー入力を受けるダイアログとページ）をテストしています。

「フェイル・ファスト」（キャッチなし）の欠点は、問題を見つけ出し、修正して実行し、新しいものを見つける（「リンスとリピート」）ことですが、ユニット・テストに使用する場合、テストのモジュール性（理想的には、テストごとに項目の1つの側面のみをテストしています）。