Cobertura de código en Java con EclEmma no escaneando esperando métodos de excepción

Question

Estoy tratando de obtener la cobertura de mi código en java, usando Eclipse y EclEmma.

Mis pruebas están utilizando JUnit 4 y tengo algunas pruebas en busca de esta manera:

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

Y EclEmma dice que la prueba falla porque no hay una IllegalArgumentException ser lanzado. Por lo tanto, se quita el indicador de cobertura de código aunque se supone que arroja algo. ¿Hay alguna opción para que vea que JUnit esperaba la etiqueta de excepción?

editar: ¡He descubierto que si agrega el lanzamiento a la declaración de la prueba también, funciona!

Answer 1

No, no hay forma de que EclEmma advierta la cláusula expected. Ellos reconocen este hecho here.

¿Por qué casos de prueba junit4 con las excepciones que se espera que se muestran como no cubiertos?

Los casos de prueba JUnit4 con excepciones esperadas se muestran como no cubiertos aunque se hayan ejecutado. La razón para esto es que la biblioteca de cobertura de código subyacente de JaCoCo solo considera que el código se ejecuta cuando se ejecutan ciertas sondas. Para casos de prueba exitosos marcados con @Test{expected=...}, este no es el caso.

Personalmente, no me preocuparía demasiado al respecto. La cobertura de casos de prueba es lo menos interesante que EclEmma puede decirle; Siempre ignoro completamente esas métricas y me concentro en la cobertura de mi código de producción.

Answer 2

Me enfrenté al mismo problema y ofrecí una solicitud de extracción para tratar la causa más importante de esta molestia. En lugar de agregar demasiadas sondas, solo trato con los códigos de operación de las invocaciones de métodos. En otras palabras, se resuelve el problema de los resultados de cobertura (previamente) erróneos causados ​​por una excepción lanzada por una invocación de método, pero no si la excepción es, por ejemplo, una división por cero, un reparto incorrecto o un índice de matriz problema.

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

Siéntase libre de comentar sobre la solicitud de extracción o participar en la discusión que empecé en la lista de correo JaCoCo.

Answer 3

no puede hacer comentarios todavía, pero quería señalar, en relación con la respuesta aceptada, de que hay una muy buena razón para prestar atención a la cobertura de su código de prueba.

Con JUnit es fácil deshacer el método de prueba nombrando las convenciones u olvidando la anotación @Test, dependiendo de su versión JUnit. Hazlo y fácilmente te podrían engañar para que pienses que tu barra verde sólida significa que pasó la prueba agradable que acabas de agregar, cuando en realidad nunca se ejecutó. El coloreado de cobertura lo mostrará de manera muy prominente. Excepto, por supuesto, ya que este hilo señala, algunas de las pruebas que generen excepciones podría parecer que no se ha ejecutado cuando lo hicieron.