====== 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:

<sxh java>
@ApplicationModuleTest
class OrderIntegrationTests {
    // Pruebas del módulo orders.
}
</sxh>

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.

<sxh java>
scenario.publish(new OrderCompleted(42L))
        .andWaitForEventOfType(StockReserved.class)
        .matching(event -> event.orderId().equals(42L))
        .toArriveAndVerify(event -> assertEquals(42L, event.orderId()));
</sxh>

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).