JUnitテストケースで「失敗」の実際の使用は何ですか？

JUnitテストケースで「失敗」の実際の使用は何ですか？

私がそれが便利であるとわかったいくつかのケース：

• 不完全なテストにマークを付けると、失敗し、完了するまで警告が表示されます
• 例外がスローされることを確認します。

try{
  // do stuff...
  fail("Exception not thrown");
}catch(Exception e){
  assertTrue(e.hasSomeFlag());
}

注意：

JUnit4以降、例外がスローされていることをテストするより洗練された方法があります。アノテーションを使用します @Test(expected=IndexOutOfBoundsException.class)

ただし、これも例外を検査したい場合は機能しませんfail()。

テストするコードが例外を発生させる-veフローのテストケースを書いているとしましょう

try{
   bizMethod(badData);
   fail(); // FAIL when no exception is thrown
} catch (BizException e) {
   assert(e.errorCode == THE_ERROR_CODE_U_R_LOOKING_FOR)
}

通常のユースケースは、否定的なテストで例外がスローされなかったときにそれを呼び出すことだと思います。

次の疑似コードのようなもの：

test_addNilThrowsNullPointerException()
{
    try {
        foo.add(NIL);                      // we expect a NullPointerException here
        fail("No NullPointerException");   // cause the test to fail if we reach this            
     } catch (NullNullPointerException e) {
        // OK got the expected exception
    }
}

@Beforeメソッドで何か問題が発生した可能性がある場合に使用しました。

public Object obj;

@Before
public void setUp() {
    // Do some set up
    obj = new Object();
}

@Test
public void testObjectManipulation() {
    if(obj == null) {
        fail("obj should not be null");
     }

    // Do some other valuable testing
}

これがFailメソッドの使用方法です。

テストケースが終了する可能性のある3つの状態があります。

1. 合格：テスト対象の関数が正常に実行され、期待どおりにデータが返されました
2. 不合格：テスト対象の関数は正常に実行されましたが、返されたデータが期待どおりではありませんでした
3. 失敗しました：関数は正常に実行されませんでした。

意図した（例外の発生を期待する否定的なテストケースとは異なります）。

日食を使用している場合、3つの状態がそれぞれ緑、青、赤のマーカーで示されます。

3番目のシナリオでは、失敗操作を使用します。

例：public Integer add（integer a、Integer b）{return new Integer（a.intValue（）+ b.intValue（））}

1. 渡されたケース：a = new Interger（1）、b = new Integer（2）、関数は3を返しました
2. 渡されなかった場合：a = new Interger（1）、b = new Integer（2）、関数は3以外のsoem値を返しました
3. 失敗した場合：a = null、b = nullで、関数はNullPointerExceptionをスローします

たとえば、fail()まだ終了していない（発生している）テストを示すために使用します。それ以外の場合は、成功と表示されます。

これはおそらく、NUnitに存在するある種のincomplete（）機能に気付いていないためです。

同時および/または非同期の設定では、特定のメソッド（デリゲート、イベントリスナー、応答ハンドラーなど）が呼び出されていないことを確認する必要がある場合があります。フレームワークのモックは別としてfail()、それらのメソッドを呼び出してテストを失敗させることができます。期限切れのタイムアウトは、このようなシナリオでのもう1つの自然な障害状態です。

例えば：

final CountDownLatch latch = new CountDownLatch(1);

service.asyncCall(someParameter, new ResponseHandler<SomeType>() {
    @Override
    public void onSuccess(SomeType result) {
        assertNotNull(result);
        // Further test assertions on the result
        latch.countDown();
    }

    @Override
    public void onError(Exception e) {
        fail(exception.getMessage());
        latch.countDown();
    }
});

if ( !latch.await(5, TimeUnit.SECONDS) ) {
    fail("No response after 5s");
}

最も重要なユースケースはおそらく例外チェックです。

junit4には、例外が発生したかどうかを確認するために必要な要素が含まれていますが、新しいjunit5の一部ではないようです。を使用fail()するもう1つの利点は、テストケースのクリーンアップexpectedをfinally可能にすることと組み合わせることができることです。

dao.insert(obj);
try {
  dao.insert(obj);
  fail("No DuplicateKeyException thrown.");
} catch (DuplicateKeyException e) {
  assertEquals("Error code doesn't match", 123, e.getErrorCode());
} finally {
  //cleanup
  dao.delete(obj);
}

別のコメントで述べたように。テストの実装が完了するまでテストを失敗させることも、妥当と思われます。