Qual è l'uso effettivo di "fail" nel caso di test JUnit?

Question

Qual è l'uso effettivo di "fail" nel caso di test JUnit?

Answer 1

Alcuni casi in cui ho trovato utile:

• contrassegnare un test che è incompleta, in modo che non riesce e si avverte fino a quando si può finirlo
• assicurandosi viene generata un'eccezione:

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

Nota:

Dal JUnit4, c'è un modo più elegante per testare che un'eccezione viene gettata: usare l'annotazione @Test(expected=IndexOutOfBoundsException.class)

Tuttavia, questo non funzionerà se anche vuoi controllare l'eccezione, quindi hai ancora bisogno di fail().

Answer 2

Penso che il caso di utilizzo normale sia quello di chiamarlo quando nessuna eccezione è stata lanciata in un test negativo.

Qualcosa come il seguente pseudo-codice:

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 
    } 
} 

Answer 3

Diciamo che si sta scrivendo un banco di prova per un flusso ve in cui il codice in fase di sperimentazione dovrebbe sollevare un'eccezione

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

Answer 4

Questo è come io uso il metodo Fail.

ci sono tre stati che il tuo caso di test può finire in

1. Superato: la funzione in prova eseguita con successo e restituito dati come previsto
2. non passato: la funzione in prova eseguita con successo, ma la dati restituiti non era come previsto
3. Impossibile: La funzione non è stata eseguita con successo e questo non era

previsti (a differenza dei casi di test negativi che prevedono un'eccezione a ).

Se si utilizza eclissi, tre stati sono indicati rispettivamente da un indicatore verde, blu e rosso.

Uso l'operazione di errore per il terzo scenario.

ad es. : public Integer add (intero a, Integer b) {return new Integer (a.intValue() + b.intValue())}

1. Superato il caso: a = new interger (1), b = new Integer (2) e la funzione restituito 3
2. caso non passato: a = new interger (1), b = new Integer (2) e la funzione ha restituito valore soem diverso da 3
3. caso riuscito: a = null, b = null e la funzione lancia una NullPointerException

Answer 5

ho usato nel caso in cui qualcosa potrebbe essere andato storto nel mio metodo @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 
} 

Answer 6

Io, per esempio, utilizzare fail() indicare prove che non sono ancora finiti (succede); altrimenti, mostrerebbero il successo.

Questo è forse dovuto al fatto che non sono a conoscenza di una sorta di funzionalità incomplete(), che esiste in NUnit.

Answer 7

utilizzare semplicemente:

org.junit.Assert.fail("Exception expected"); 

Answer 8

Il caso d'uso più importante è probabilmente la verifica un'eccezione.

Mentre junit4 include expected element per verificare se si è verificata un'eccezione, sembra che non faccia parte della più recente junit5. Un altro vantaggio dell'utilizzo di fail() su expected è che è possibile combinarlo con finally consentendo la pulizia del caso di test.

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); 
} 

Come indicato in un altro commento. Avere un test per fallire fino a quando non è possibile completare l'implementazione sembra ragionevole.