Dobles de prueba con Mockito

Aquí tiene un test que pasa, que cuenta para la cobertura y que no detecta absolutamente nada:

@Test
void le_service_retourne_le_client() {
    when(depot.parId(7L)).thenReturn(new Client(7L, "Dupont"));

    Client client = service.trouver(7L);

    assertThat(client.nom()).isEqualTo("Dupont");
}

Ha declarado que el repositorio devuelve «Dupont» y luego ha verificado que sale «Dupont». El único comportamiento que se prueba es el de Mockito. Sustituya la implementación de service.trouver por return depot.parId(id);, eliminando toda la lógica de negocio que contenía: el test sigue en verde. Es el defecto más extendido en las suites que abusan de los dobles, y el contador de cobertura no lo detecta: mostrará orgullosamente un 100 % en el método.

Mockito es una excelente herramienta mal utilizada por defecto. El reflejo de «una clase probada, todos los colaboradores simulados» produce tests que describen la estructura interna del código en lugar de su comportamiento: cada traslado de responsabilidad entre dos clases rompe diez tests sin que se haya introducido ningún bug. Esta lección establece una regla sencilla para decidir cuándo está justificado un doble y muestra cómo verificar interacciones sin arrinconarse.