04 - Pruebas de integración de módulos
Spring Modulith permite iniciar módulos de aplicación de forma aislada o junto con sus dependencias, para probar la integración con un contexto Spring más acotado que el de toda la aplicación.
1. Pruebas de un módulo
Se añade el starter de pruebas y se coloca @ApplicationModuleTest en una clase del paquete del módulo o de uno de sus subpaquetes:
@ApplicationModuleTest
class OrderIntegrationTests {
// Pruebas del módulo orders.
}
Por defecto se inicia únicamente el módulo actual (STANDALONE). También se puede incluir:
| Modo | Módulos cargados |
|---|---|
| STANDALONE | El módulo de la prueba |
| DIRECT_DEPENDENCIES | El módulo y sus dependencias directas |
| ALL_DEPENDENCIES | El módulo y todas sus dependencias transitivas |
La prueba configura el escaneo de componentes y auto-configuración para los paquetes incluidos.
2. Dependencias hacia otros módulos
Si un bean del módulo necesita un bean de otro módulo y este no está incluido, el arranque puede fallar. En pruebas centradas en un módulo suele convenir simular la dependencia externa con @MockitoBean en vez de ampliar el contexto sin necesidad.
Muchas dependencias hacia otros módulos pueden indicar acoplamiento elevado; conviene revisar si algunas colaboraciones pueden expresarse mediante eventos.
3. Combinar pruebas verticales y slices
@ApplicationModuleTest delimita la aplicación por módulo (corte vertical). @ModuleSlicing permite combinar ese límite con las pruebas por capa de Spring Boot, como @DataJpaTest (corte horizontal).
4. Escenarios con eventos
La API Scenario simplifica pruebas de listeners transaccionales y asíncronos. Un escenario:
- Publica un evento o invoca un bean expuesto por el módulo.
- Configura opcionalmente el tiempo máximo de espera.
- Espera un evento resultante o un cambio de estado observable.
- Verifica el evento o resultado.
scenario.publish(new OrderCompleted(42L))
.andWaitForEventOfType(StockReserved.class)
.matching(event -> event.orderId().equals(42L))
.toArriveAndVerify(event -> assertEquals(42L, event.orderId()));
La publicación estímulo se ejecuta en una transacción nueva para que los listeners transaccionales puedan procesarla. Los cambios de estado persistidos no se revierten automáticamente al terminar el test; se limpian explícitamente.
5. Ejecución de tests sensible a cambios
El artefacto spring-modulith-junit puede omitir pruebas de módulos no afectados por los cambios. En general ejecuta pruebas del módulo modificado y de módulos que dependen de él. La optimización se desactiva en casos como cambios de build o recursos de classpath, ejecuciones explícitas desde el IDE o ausencia de cambios detectables.
En CI se puede configurar un commit de referencia para determinar qué archivos cambiaron. La propiedad spring.modulith.test.on-no-changes permite elegir qué hacer si no se detectan cambios.
Referencia
- [Documentación oficial: Integration Testing Application Modules](https://docs.spring.io/spring-modulith/reference/testing.html) (Spring Modulith 2.1.1).