2012-07-11 22 views
7

Ho codice in cui verifico le eccezioni in JUnit. Voglio sapere quale dei seguenti è una buona pratica JUnit?Che è meglio, ExpectedException o @Test (expected =

Prima

@Rule 
public ExpectedException exception = ExpectedException.none(); 

@Test 
public void checkNullObject() throws CustomException { 
    exception.expect(CustomException.class); 
    MyClass myClass= null; 
    MyCustomClass.get(null); 
} 

seconda

@Test(expected=CustomException.class) 
public void checkNullObject() throws CustomException { 
    MyClass myClass= null; 
    MyCustomClass.get(null);  
} 

EDIT: Si noti che CustomException è un'eccezione personalizzata non controllata. (Anche se non avrà alcun impatto su questa domanda).

+0

Io uso il secondo modulo. –

+0

Usiamo anche il secondo modulo. – SWoeste

+1

O un duplicato di http://stackoverflow.com/questions/785618/in-java-how-can-i-validate-a-thrown-exception-with-junit o principalmente opinion based – Raedwald

risposta

10

Dipende da cosa si desidera controllare nell'eccezione. Se tutto quello che stai facendo è verificare che l'eccezione viene generata, quindi utilizzando @Test(expected=...) è probabilmente il modo più semplice:

@Test(expected=CustomException.class) 
public void checkNullObject() throws CustomException { 
    MyClass myClass= null; 
    MyCustomClass.get(null); 
} 

Tuttavia, il @Rule ExpectedException ha molte più opzioni, tra cui il controllo del messaggio, dal javadoc :

// These tests all pass. 
public static class HasExpectedException { 
    @Rule 
    public ExpectedException thrown= ExpectedException.none(); 

    @Test 
    public void throwsNothing() { 
     // no exception expected, none thrown: passes. 
    } 

    @Test 
    public void throwsNullPointerException() { 
     thrown.expect(NullPointerException.class); 
     throw new NullPointerException(); 
    } 

    @Test 
    public void throwsNullPointerExceptionWithMessage() { 
     thrown.expect(NullPointerException.class); 
     thrown.expectMessage("happened?"); 
     thrown.expectMessage(startsWith("What")); 
     throw new NullPointerException("What happened?"); 
    } 

    @Test 
    public void throwsIllegalArgumentExceptionWithMessageAndCause() { 
     NullPointerException expectedCause = new NullPointerException(); 
     thrown.expect(IllegalArgumentException.class); 
     thrown.expectMessage("What"); 
     thrown.expectCause(is(expectedCause)); 
     throw new IllegalArgumentException("What happened?", cause); 
    } 
} 

Quindi è possibile verificare il messaggio, la causa originale dell'eccezione. Per controllare il messaggio, è possibile utilizzare i corrispondenti, in modo da poter controllare startsWith() e simili.

Un motivo per utilizzare il vecchio stile (Junit 3) tiro/presa è se si hanno requisiti specifici. Non ci sono molti di questi, ma può succedere:

@Test 
public void testMe() { 
    try { 
     Integer.parseInt("foobar"); 
     fail("expected Exception here"); 
    } catch (Exception e) { 
     // OK 
    } 
} 
1

La seconda versione è sicuramente il modo standard per farlo. Il modo vecchia scuola per farlo, prima di Junit 4 sembrava:

try { 
    codeThatShouldThrowException(); 
    fail("should throw exception"); 
} catch (ExpectedException expected) { 
    //Expected 
} 

A volte si potrebbe desiderare di tornare a questo modo, per esempio se si vuole far valere qualcosa circa il messaggio nella eccezione.

+0

Penso che anche se vogliamo controlla qualcosa sul messaggio di eccezione, possiamo andare con [in questo modo] (http://stackoverflow.com/questions/11413922/check-errorcode-with-rule-in-junit). Non c'è bisogno di usare questo try -fail - catch construct –