Spring proporciona las siguientes implementaciones TestExecutionListener, que están registradas de forma predeterminada, exactamente en el siguiente orden:

  • ServletTestExecutionListener: configura objetos simulados de API de servlet para WebApplicationContext.

  • DirtiesContextBeforeModesTestExecutionListener: maneja la anotación @DirtiesContext para los modos "antes".

  • ApplicationEventsTestExecutionListener: proporciona soporte para ApplicationEvents.

  • DependencyInjectionTestExecutionListener: proporciona inyección de dependencia para la instancia de prueba.

  • DirtiesContextTestExecutionListener: maneja la anotación @DirtiesContext para los modos posteriores.

  • TransactionalTestExecutionListener: proporciona ejecución transaccional de pruebas con semántica de reversión predeterminada.

  • SqlScriptsTestExecutionListener: ejecuta scripts SQL configurados con la anotación @Sql.

  • EventPublishingTestExecutionListener: publica eventos de ejecución de prueba
    en ApplicationContext.

Registro de implementaciones de TestExecutionListener

Puede registrar implementaciones TestExecutionListener para una clase de prueba y sus subclases utilizando la anotación @TestExecutionListeners. Para obtener detalles y ejemplos, consulte la subsección de soporte de anotaciones y el javadoc de anotaciones @TestExecutionListeners .

Detección automática de implementaciones TestExecutionListener predeterminadas

Registrar implementaciones TestExecutionListener con la anotación @TestExecutionListeners es adecuado para escuchas especiales que se utilizan en escenarios de prueba limitados. Sin embargo, el registro puede resultar difícil si es necesario utilizar un oyente personalizado en todo el conjunto de pruebas. Este problema se soluciona admitiendo la detección automática de implementaciones TestExecutionListener de forma predeterminada a través del mecanismo SpringFactoriesLoader.

Java university

Específicamente, el módulo spring-test declara todas las implementaciones TestExecutionListener predeterminadas en la clave org.springframework.test.context.TestExecutionListener en el propiedades del archivo META-INF/spring.factories. Los desarrolladores y marcos de trabajo de terceros pueden agregar sus propias implementaciones TestExecutionListener a la lista de escuchas predeterminada de la misma manera a través de su propio archivo de propiedades META-INF/spring.factories.

Ordenar TestExecutionListener

Si el marco TestContext descubre implementaciones TestExecutionListener predeterminadas a través del mecanismo SpringFactoriesLoader anterior, las instancias de escucha creadas se ordenan utilizando el AnnotationAwareOrderComparator de su Spring. , que respeta la interfaz Ordered de Spring y la anotación @Order para realizar pedidos. AbstractTestExecutionListener y todas las implementaciones predeterminadas de TestExecutionListener proporcionadas por Spring implementan Ordered con los valores apropiados. Por lo tanto, los desarrolladores y marcos de trabajo de terceros deben asegurarse de que sus implementaciones TestExecutionListener predeterminadas se registren en el orden correcto implementando Ordered o declarando la anotación @Order. . Consulte el javadoc sobre los métodos getOrder() de las implementaciones predeterminadas de TestExecutionListener para obtener más detalles sobre qué valores se asignan a cada oyente principal.

Combinando implementaciones TestExecutionListener

Si un oyente personalizado TestExecutionListener se registra mediante la anotación @TestExecutionListeners, los oyentes no se registran de forma predeterminada. En los escenarios de prueba más comunes, esto obliga efectivamente al desarrollador a declarar manualmente todos los oyentes predeterminados además de los oyentes personalizados. La siguiente lista demuestra este estilo de configuración:

Java
@ContextConfiguration
@TestExecutionListeners({
    MyCustomTestExecutionListener.clase,
    ServletTestExecutionListener.clase,
    DirtiesContextBeforeModesTestExecutionListener.clase,
    DependencyInjectionTestExecutionListener.clase,
    DirtiesContextTestExecutionListener.clase,
    TransactionalTestExecutionListener.clase,
    Clase SqlScriptsTestExecutionListener.
})
clase MiPrueba {
    // cuerpo de la clase...
}
Kotlin
@ContextConfiguration
@TestExecutionListeners(
    MyCustomTestExecutionListener::clase,
    ServletTestExecutionListener::clase,
    DirtiesContextBeforeModesTestExecutionListener::clase,
    DependencyInjectionTestExecutionListener::clase,
    DirtiesContextTestExecutionListener::clase,
    TransactionalTestExecutionListener::clase,
    SqlScriptsTestExecutionListener::clase
)
clase MiPrueba {
    // cuerpo de la clase...
}

La dificultad de este enfoque es que requiere que el desarrollador sepa exactamente qué oyentes están registrados de forma predeterminada. Además, el conjunto de oyentes predeterminados puede cambiar de una versión a otra; por ejemplo, el oyente SqlScriptsTestExecutionListener se introdujo en Spring Framework 4.1 y el oyente DirtiesContextBeforeModesTestExecutionListener se introdujo en Spring Framework. 4.2. Además, los marcos de trabajo de terceros, como Spring Boot y Spring Security, registran sus propias implementaciones TestExecutionListener predeterminadas utilizando el mecanismo de detección automática antes mencionado.

Para evitar tener que conocer y volver a declarar todos los oyentes predeterminados, puede establecer el atributo mergeMode de la anotación @TestExecutionListeners en MergeMode.MERGE_WITH_DEFAULTS. MERGE_WITH_DEFAULTS especifica que los oyentes declarados localmente deben fusionarse con los oyentes predeterminados. El algoritmo de combinación garantiza que los duplicados se eliminen de la lista y que el conjunto resultante de oyentes combinados se ordene según la semántica de AnnotationAwareOrderComparator, como se describe en las implementaciones "Ordenar TestExecutionListener". sección. Si un oyente implementa Ordered o está marcado con la anotación @Order, puede influir en la posición en la que se combina con los oyentes predeterminados. De lo contrario, los oyentes declarados localmente se agregan a la lista de oyentes predeterminada cuando se fusionan.

Por ejemplo, si la clase MyCustomTestExecutionListener del ejemplo anterior configuró su valor order (por ejemplo, 500) para que sea menor que el valor del pedido ServletTestExecutionListener (que es 1000), entonces MyCustomTestExecutionListener se puede combinar automáticamente con una lista de valores predeterminados antes de ServletTestExecutionListener, y el ejemplo anterior se puede sustituir por el siguiente:

Java
@ContextConfiguration
@TestExecutionListeners(
    oyentes = MyCustomTestExecutionListener.class,
    modo de fusión = MERGE_WITH_DEFAULTS
)
clase MiPrueba {
    // cuerpo de la clase...
}
Kotlin
@ContextConfiguration
@TestExecutionListeners(
        oyentes = [MyCustomTestExecutionListener::clase],
        modo de fusión = MERGE_WITH_DEFAULTS
)
clase MiPrueba {
    // cuerpo de la clase...
}