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.
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.
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.
@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).
La API Scenario simplifica pruebas de listeners transaccionales y asíncronos. Un escenario:
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.
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.