TestNG: come verificare le eccezioni obbligatorie?

Question

Vorrei scrivere un test TestNG per assicurarmi che venga generata un'eccezione in una condizione specifica e non rieseguire il test se l'eccezione non viene generata. C'è un modo semplice per farlo senza dover creare una variabile booleana extra?

Un relativo post sul blog su questo argomento: http://konigsberg.blogspot.com/2007/11/testng-and-expectedexceptions-ive.html

Answer 1

@Test(expectedExceptions) è utile per i casi più comuni:

• ci si aspetta una specifica deroga essere gettato
• è necessario il messaggio di tale eccezione per contenere parole specifiche

Per la documentazione un test fallirà se non viene lanciato alcun expectedException:

L'elenco di eccezioni che si prevede che un metodo di prova lanci. Se non viene lanciata alcuna eccezione o una diversa da questa lista, questo test verrà contrassegnato come non riuscito.

Ecco alcuni scenari in cui @Test(expectedExceptions) non è sufficiente:

• tuo metodo di prova ha diverse dichiarazioni e solo si prevede uno di loro di gettare
• si sta gettando il proprio tipo di eccezione e è necessario assicurarsi che corrisponda un certo criterio

In questi casi, si deve solo tornare al tradizionale (pre-TestNG) modello:

try { 
    // your statement expected to throw 
    fail(); 
} 
catch(<the expected exception>) { 
    // pass 
} 

Answer 2

Perché non utilizzare il modello di try/fallire/catture citati nel post del blog si è collegato al?

Answer 3

Non sono d'accordo con l'articolo sulla natura delle tecniche di prova utilizzate. La soluzione utilizza un gate per verificare se il test deve avere esito positivo o negativo in uno stadio intermedio.

A mio parere, è meglio impiegare Guard Assertions, in particolare per tali test (presupponendo che il test non risulti essere prolisso e complesso, che è un anti-pattern di per sé). Utilizzando guard-asserzioni forze di progettare il SUT in uno dei seguenti modi:

• disegno il metodo stesso di fornire informazioni sufficienti nel risultato se l'invocazione superato o è riuscito. A volte, questo non può essere fatto in quanto l'intenzione del progettista è di non restituire un risultato, e invece di lanciare un'eccezione (che può essere gestita nel secondo caso).
• progettare il SUT in modo che sia state can be verified dopo ogni richiamo del metodo significativo.

Ma prima di considerare le possibilità di cui sopra, date un'occhiata al seguente frammento di nuovo:

plane.bookAllSeats(); 
plane.bookPlane(createValidItinerary(), null); 

Se l'intenzione è quella di testare bookPlane() e verificare per l'esecuzione di tale metodo, è meglio avere bookAllSeats() in un dispositivo. A mio avviso, invocare bookAllSeats() equivale a configurare SUT per garantire che l'invocazione di bookPlane() fallisca, e quindi avere un dispositivo per fare lo stesso farebbe un test più leggibile. Se l'intenzione è diversa, consiglierei di testare lo stato dopo ogni transizione (come normalmente farei nei test funzionali), per aiutare a individuare la causa originale dell'insuccesso.

Answer 4

catch-exception fornisce probabilmente tutto ciò che è necessario verificare per le eccezioni previste.

Answer 5

@Test(expectedExceptions = AnyClassThatExtendsException.class, expectedExceptionsMessageRegExp = "Exception message regexp") 

O se non si vuole verificare la presenza di messaggio di eccezione, solo al di sotto è abbastanza

@Test(expectedExceptions = AnyClassThatExtendsException.class) 

In questo modo, non c'è bisogno di utilizzare brutto blocco try catch, basta invocare te metodo di lancio delle eccezioni all'interno del test.