Jawaban:
Beberapa kasus yang menurut saya berguna:
try{ // do stuff... fail("Exception not thrown"); }catch(Exception e){ assertTrue(e.hasSomeFlag()); }
catatan:
Sejak JUnit4, ada cara yang lebih elegan untuk menguji pengecualian yang dilemparkan: Gunakan anotasi @Test(expected=IndexOutOfBoundsException.class)
Namun, ini tidak akan berhasil jika Anda juga ingin memeriksa pengecualian, maka Anda masih perlu fail()
.
Saya pikir kasus penggunaan yang biasa adalah memanggilnya ketika tidak ada pengecualian yang dilemparkan dalam tes negatif.
Sesuatu seperti pseudo-code berikut:
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
}
}
Saya telah menggunakannya dalam kasus di mana ada sesuatu yang salah dalam metode @Before saya.
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
}
@Before
metode tersebut berhasil, mungkin lebih baik untuk memeriksanya secara langsung di metode tersebut. Sebagai bonus, setidaknya JUnit dan TestNG bahkan akan melaporkan kegagalan yang berbeda untuk kesalahan dari @Before
/ @After
metode, jadi dapat dilihat bahwa masalahnya tidak ada dalam pengujian itu sendiri.
Beginilah cara saya menggunakan metode Gagal.
Ada tiga status tempat uji kasus Anda dapat berakhir
dimaksudkan (Tidak seperti kasus uji negatif yang mengharapkan pengecualian terjadi).
Jika Anda menggunakan gerhana, ada tiga status yang masing-masing ditunjukkan oleh penanda Hijau, Biru, dan merah.
Saya menggunakan operasi gagal untuk skenario ketiga.
contoh: public Integer add (integer a, Integer b) {return new Integer (a.intValue () + b.intValue ())}
fail()
.
Saya, misalnya, menggunakan fail()
untuk menunjukkan tes yang belum selesai (itu terjadi); jika tidak, mereka akan tampil sebagai sukses.
Ini mungkin karena fakta bahwa saya tidak mengetahui beberapa jenis fungsi yang tidak lengkap (), yang ada di NUnit.
Dalam pengaturan bersamaan dan / atau asynchronous, Anda mungkin ingin memverifikasi bahwa metode tertentu (misalnya delegasi, event listener, penangan respons, sebut saja) tidak dipanggil. Kerangka mengolok-olok samping, Anda dapat meneleponfail()
metode tersebut untuk gagal dalam pengujian. Batas waktu kedaluwarsa adalah kondisi kegagalan alami lainnya dalam skenario semacam itu.
Sebagai contoh:
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");
}
Kasus penggunaan yang paling penting mungkin adalah pemeriksaan pengecualian.
Meskipun junit4 menyertakan elemen yang diharapkan untuk memeriksa jika terjadi pengecualian, sepertinya ini bukan bagian dari junit5 yang lebih baru. Keuntungan lain menggunakan fail()
over the expected
adalah Anda dapat menggabungkannya dengan finally
mengizinkan pembersihan kasus uji.
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);
}
Sebagaimana dicatat dalam komentar lain. Menguji gagal sampai Anda dapat menyelesaikan penerapannya juga terdengar masuk akal.