Cobertura frente al código alcanzable

Question

P: ¿cómo detectar la cobertura de prueba real?

He notado un problema con la métrica de cobertura de código y la calidad de la prueba: la cobertura de código 100% no significa que el código esté realmente probado.

A veces la prueba ofrece una cobertura del 100%, incluso si no cubre todo. El problema se establece en la definición de cobertura, suponemos cobertura == código alcanzable.

Pero no es cierto, el código podría ser 100% alcanzable pero no cubierto al 100% con la prueba.

Eche un vistazo al ejemplo, esta prueba ofrece una cobertura del 100% (EMMA), pero en realidad no cubre los valores que se pasarán a la simulación del servicio. Entonces, si se cambiará el valor, la prueba no fallará.

Ejemplo:

public class User { 
    public static final int INT_VALUE = 1; 
    public static final boolean BOOLEAN_VALUE = false; 
    public static final String STRING_VALUE = ""; 
    private Service service; 

    public void setService(Service service) { 
     this.service = service; 
    } 

    public String userMethod() { 
     return service.doSomething(INT_VALUE, BOOLEAN_VALUE, STRING_VALUE); 
    } 
} 

y prueba de ello:

public class UserTest { 

    private User user; 
    private Service easyMockNiceMock; 

    @Before 
    public void setUp() throws Exception { 
     user = new User(); 
     easyMockNiceMock = EasyMock.createNiceMock(Service.class); 
    } 

    @Test 
    public void nonCoverage() throws Exception { 
     // given 
     user.setService(easyMockNiceMock); 
     expect(easyMockNiceMock.doSomething(anyInt(), anyBoolean(), (String) anyObject())).andReturn(""); 
     replay(easyMockNiceMock); 
     // when 
     user.userMethod(); 
     // then 
     verify(easyMockNiceMock); 
    } 
} 

Answer 1

Tome un vistazo a Jester, que realiza mutation testing. Del sitio:

Jester encuentra el código que no está cubierto por las pruebas. Jester hace que algunos cambien a su código, ejecuta sus pruebas, y si pasan las pruebas Jester muestra un mensaje que dice lo que cambió. Jester incluye un script para generar páginas web que muestran los cambios realizados que no causaron que las pruebas fallaran.

Jester es diferente de las herramientas de cobertura de código, porque puede encontrar el código que se ejecuta ejecutando pruebas pero no realmente probado. El enfoque de Jester se denomina prueba de mutación o error automático siembra. Sin embargo, Jester no pretende reemplazar las herramientas de cobertura del código , simplemente como un enfoque complementario.

Answer 2

El 100% de cobertura nunca ha significado que el 100% de las pruebas haya sido probada, y cualquiera que haya dicho que lo hizo no entiende o le miente. La medición de cobertura simplemente mide qué código de producto se ha ejecutado durante la prueba. Hay docenas de formas de escribir pruebas que producen una cobertura del 100%, y luego no prueban completamente el código.

La manera más simple es escribir una prueba que llame a la función del producto, ¡y luego nunca hace ninguna afirmación sobre el valor de retorno!

Aquí hay una publicación de blog que escribí sobre este mismo tema: Flaws in Coverage Measurement, está centrada en Python, pero los conceptos son todos iguales.