Objetos Mock y Fixtures en Java: cómo probar más rápido y de manera más inteligente

Por qué fallan tus pruebas Java (y cómo solucionarlo)

Escribiste el código perfecto. El servicio funciona, la lógica es impecable y los errores solo están en proyectos ajenos. Pero cuando ejecutas las pruebas... Ahí hay un error de conexión a la BD, aquí una API externa no responde, y en la tercera prueba, un NullPointerException porque la configuración no se levantó correctamente. ¿Te suena familiar?

El problema es que las pruebas clásicas dependen del entorno externo. Base de datos, servicios REST, sistema de archivos: todo esto hace que las pruebas sean frágiles, lentas e impredecibles. La solución son los objetos mock y las fixtures. No son solo palabras de moda, sino herramientas que convierten el caos en orden.

En este artículo, analizaremos cómo usar correctamente los mocks y fixtures en pruebas Java con ejemplos reales. Aprenderás la diferencia entre stub y mock, cómo configurar fixtures para escenarios complejos y por qué Mockito es tu mejor amigo. ¡Allá vamos!

Objetos Mock: simulación sin dolor

¿Qué es un mock y para qué sirve?

Un objeto mock es una imitación de un componente real que se comporta como tú le indiques. En lugar de levantar una base de datos o llamar a una API externa, creas un "simulacro" que devuelve datos predefinidos.

Imagina que estás probando un servicio que envía notificaciones por correo electrónico. Para una prueba real, necesitarías levantar un servidor de correo, configurar SMTP, verificar la cola... Pero con un objeto mock, simplemente verificas que el servicio llamó al método de envío con los parámetros correctos. Rápido, limpio y controlable.

Mock vs Stub: ¿cuál es la diferencia?

Los principiantes suelen confundir estos conceptos. Aclaremos las cosas:

\n
• Stub: devuelve datos fijos. Le dices: "Cuando se llame al método getUser(), devuelve un objeto User con el nombre 'John'". El stub no verifica cuántas veces fue llamado.
\n
• Mock: no solo devuelve datos, sino que también verifica el comportamiento. Puedes decir: "Asegúrate de que el método sendEmail() se haya llamado exactamente una vez con una dirección específica".
\n

En términos simples: stub es "dame datos", mock es "dame datos y verifica cómo me usan". En la práctica, se usan más los objetos mock porque ofrecen mayor control.

Escribiendo nuestro primer mock con Mockito

Mockito es la biblioteca más popular para mocks en Java. Se integra con JUnit 5 y Spring Boot, y su sintaxis es tan simple que la recordarás en cinco minutos.

Supongamos que tienes un servicio OrderService que depende de un repositorio OrderRepository. En lugar del repositorio real, crearemos un mock:

import static org.mockito.Mockito.*;\nimport org.junit.jupiter.api.Test;\nimport org.mockito.Mock;\nimport org.mockito.junit.jupiter.MockitoExtension;\nimport org.junit.jupiter.api.extension.ExtendWith;\n\n@ExtendWith(MockitoExtension.class)\npublic class OrderServiceTest {\n\n    @Mock\n    private OrderRepository orderRepository;\n\n    @Test\n    void testCreateOrder() {\n        // Creamos el objeto mock\n        OrderService orderService = new OrderService(orderRepository);\n        \n        // Configuramos el comportamiento del mock\n        when(orderRepository.save(any(Order.class)))\n            .thenReturn(new Order(1L, "test@example.com", 100.0));\n        \n        // Llamamos al método bajo prueba\n        Order result = orderService.createOrder("test@example.com", 100.0);\n        \n        // Verificamos el resultado\n        assertThat(result.getId()).isEqualTo(1L);\n        // Verificamos que el método save se haya llamado exactamente una vez\n        verify(orderRepository, times(1)).save(any(Order.class));\n    }\n}

En este ejemplo:

\n
• Creamos un mock para OrderRepository usando la anotación @Mock.
\n
• Configuramos que al llamar a save() se devuelva un pedido creado previamente.
\n
• Verificamos