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 paraWebApplicationContext
. -
DirtiesContextBeforeModesTestExecutionListener
: maneja la anotación @DirtiesContext para los modos "antes". -
ApplicationEventsTestExecutionListener
: proporciona soporte paraApplicationEvents
. -
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
enApplicationContext
.
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
.
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:
@ContextConfiguration
@TestExecutionListeners({
MyCustomTestExecutionListener.clase,
ServletTestExecutionListener.clase,
DirtiesContextBeforeModesTestExecutionListener.clase,
DependencyInjectionTestExecutionListener.clase,
DirtiesContextTestExecutionListener.clase,
TransactionalTestExecutionListener.clase,
Clase SqlScriptsTestExecutionListener.
})
clase MiPrueba {
// cuerpo de la clase...
}
@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:
@ContextConfiguration
@TestExecutionListeners(
oyentes = MyCustomTestExecutionListener.class,
modo de fusión = MERGE_WITH_DEFAULTS
)
clase MiPrueba {
// cuerpo de la clase...
}
@ContextConfiguration
@TestExecutionListeners(
oyentes = [MyCustomTestExecutionListener::clase],
modo de fusión = MERGE_WITH_DEFAULTS
)
clase MiPrueba {
// cuerpo de la clase...
}