2011-02-06 11 views
10

Mi chiedo, per convenzione, quando un test fallisce, è opportuno:jUnit riuscirà() convenzioni

  • dire perché non è riuscito (logica di business)
  • dire perché si vede il messaggio (ad eccezione avrebbe dovuto essere gettato e non è)

Per esempio,

fail("Accessed the element which does not exist"); 

o

fail("ArrayIndexOutOfBoundException was expected but something bad happened"); 

Quale è generalmente preferito/accettato?

risposta

9

Dato che questo è un codice di prova e non dovrebbe essere incluso nella build finale, direi più verboso, meglio è. Come tale, vorrei andare con il primo - è molto più chiaro quale sia la causa principale del problema, il che rende più facile la correzione.

Eviterei il secondo in tutte le circostanze perché non è molto utile per un tester e, se in qualche modo lo rende nella versione finale, è ancora più criptico del primo per un utente finale - semplicemente non è aiuto per tester o utenti allo stesso modo.

L'altra opzione che considererei piuttosto che indicare che si è verificata un'eccezione, invece fornire dettagli dell'eccezione effettiva: ecco perché sono state inventate le tracce dello stack. Ciò fornirebbe più dettagli di entrambi i metodi elencati.

+1

Mi piace anche il tuo nome utente :) – JAM

4

Se ci fosse una convenzione su questo l'ignorerei. Dovresti dire qualunque cosa possa comunicare meglio a qualcuno che vede questo messaggio la natura del problema in modo tale da poterlo risolvere il più facilmente possibile. Troppo spesso l'aderenza a una convenzione fallisce a questo proposito.

+0

Ma se c'è una convenzione che qualcuno si aspetta che venga ignorata, può causare confusione.Quando scrivi un test, non sai chi potrebbe guardarlo tra 10 anni. Poi di nuovo ... tra 10 anni, forse la convenzione è cambiata. – dantiston

11

In primo luogo, se si prevede che l'API si prova ad un'eccezione, invece di fare un try-catch con un fail() ...

@Test 
public void testMe() { 
    try { 
     api.testThis(); 
     fail("should not reach here"); 
    } 
    catch(MyException e) {} 
} 

... si dovrebbe fare: -

@Test(expected=MyException.class) 
public void testMe() { 
    api.testThis(); 
} 

Detto questo, uso raramente lo fail(). Se ho bisogno di eseguire certi convalida e la condizione fallisce, userò più probabili affermazioni che usare fail() ... per esempio: -

... invece di ...

@Test 
public void testMe() { 
    boolean bool = api.testThis(); 
    if (!bool) { 
     fail("should be true because bla bla bla"); 
    } 
} 

... fare questo: -

@Test 
public void testMe() { 
    boolean bool = api.testThis(); 
    assertTrue("bla bla bla",bool); 
} 

Tuttavia, se si ha realmente bisogno di utilizzare fail(), essere prolisso e spiegare perché non riesce piuttosto che "non dovrebbe arrivare qui" o "dovrebbe fallire qui", perché questo non aiuta le persone che leggi i testicoli.

Concesso, questi sono solo esempi semplici .... ma penso di ottenere i miei punti. :)

+0

Non aveva visto l'eccezione prevista nella sintassi dell'annotazione precedente. Neat. – dantiston

+0

Avvertenza sull'uso dell'annotazione: se il tuo metodo può lanciare l'eccezione con diversi messaggi di errore o più di un posto, sarà meglio usare un try-catch e confrontare il messaggio di errore. Guarda questo post sul blog per maggiori dettagli: https://blog.jooq.org/2016/01/20/use-junits-expected-exceptions-sparingly/ –