Copertura del codice in Java con EclEmma non scansione in attesa di metodi di eccezione

Question

Sto cercando di ottenere la copertura del mio codice in java, utilizzando Eclipse ed EclEmma.

miei test stanno usando JUnit 4 e ho avuto alcuni test simile a questo:

@Test(expected = IllegalArgumentException.class) 
    public void createTime_withInvalidMinuteUnder0_throws(){ 
    //Arrange 
    ... 
    //Act 
    Something triggering IllegalArgumentException Here  
} 

E EclEmma dice che il test non è riuscito perché c'è un IllegalArgumentException essere gettato. Quindi cade il mio indicatore di copertura del codice anche se dovrebbe gettare qualcosa. Esiste un'opzione per far sì che venga visualizzato il tag di eccezione previsto JUnit?

modifica: ho scoperto che se si aggiunge anche il lancio alla dichiarazione del test, funziona!

Answer 1

No, non c'è modo di ottenere EclEmma per notare la clausola expected. Riconoscono questo fatto here.

Perché i casi di test JUnit4 con le eccezioni previste sono indicati come non coperti?

I casi di test JUnit4 con le eccezioni previste sono indicati come non coperti anche se sono stati eseguiti. Il motivo è che la libreria di copertura del codice JaCoCo sottostante considera solo il codice eseguito quando vengono eseguite determinate sonde. Per i casi di test di successo contrassegnati con @Test{expected=...}, questo non è il caso.

Personalmente, non mi preoccuperei troppo. La copertura dei casi di test è la cosa meno interessante che EclEmma può dirti; Ignoro sempre completamente queste metriche e mi concentro sulla copertura del mio codice di produzione.

Answer 2

Ho affrontato lo stesso problema e ho offerto una richiesta di rimozione che si occupa della causa principale di questo fastidio. Invece di aggiungere troppi sonde, mi occupo solo degli opcode delle invocazioni dei metodi. In altre parole, il problema dei (precedenti) risultati di copertura errati causati da un'eccezione generata da un'invocazione di metodo viene risolto, ma non se l'eccezione viene generata da, ad esempio, una divisione per zero, un cast errato o un indice di array problema.

https://github.com/jacoco/jacoco/pull/261

Sentitevi liberi di commentare la richiesta di pull o partecipare alla discussione ho iniziato sulla mailing list JaCoCo.

Answer 3

Non posso ancora commentare, ma volevo sottolineare, in relazione alla risposta accettata, che c'è una buona ragione per prestare attenzione alla copertura del codice di test.

È solo un modo per semplificare con JUnit la convenzione sui nomi dei metodi di prova o dimenticare l'annotazione @Test, a seconda della versione di JUnit. Fallo e potresti facilmente essere ingannato nel pensare che la tua solida barra verde significhi che il bel test appena aggiunto è passato, quando in realtà non funzionava mai. La colorazione di copertura mostrerà questo molto prominente. Tranne, naturalmente, come sottolinea questo thread, alcuni dei test che generano eccezioni potrebbero sembrare che non siano stati eseguiti quando l'hanno fatto.