tutorial - spring-boot-starter-integration

Cómo forzar una versión nueva del contexto Spring ANTES de que se ejecute la prueba

Question

Utilizo SpringJUnit4ClassRunner para escribir pruebas de integración. También utilizo @DirtiesContext para las pruebas que dejan atrás el contexto en un estado roto y que funciona bien.

Pero ahora tengo una prueba que establece una importante propiedad del sistema en un inicializador estático, que a su vez se usa en el contexto de Spring. Esto vuelve a funcionar bien cuando la prueba se ejecuta por sí sola. Pero cuando ejecuto la prueba con otras pruebas, el contexto Spring ya se creó sin ese conjunto de propiedades y mi nueva prueba la reutiliza.

¿Cómo puedo forzar la nueva creación de un contexto Spring en mi prueba, que luego utilizará la propiedad del sistema modificada?

Answer 1

A partir de la primavera 4.2, la anotación DirtiesContext admite las siguientes fases nuevas: BEFORE_CLASS , BEFORE_EACH_TEST_METHOD y BEFORE_METHOD . Así que ahora puedes hacerlo por ejemplo:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(...)
@DirtiesContext(classMode = ClassMode.BEFORE_EACH_TEST_METHOD)
public class MyTest {
..
}

Answer 2

Hay varias opciones:

1. Puede crear un contexto de resorte individual para esta prueba cargando otra configuración en él. De esa manera, su prueba será completamente independiente de cualquier otra prueba.
2. Puede crear una configuración simplificada para esta prueba. Eso lograría lo mismo pero sería más rápido.
3. Cree un conjunto de pruebas que ejecute esta prueba primero.

Answer 3

Antes de la primavera 4.2:

Desafortunadamente, solo puedo sugerir un pirateo: tiene razón, no parece haber una forma sencilla de inicializar un nuevo contexto de aplicación en lugar de utilizar un contexto de aplicación en caché. Estas son algunas de las soluciones que puedo sugerir:

1. Use una @ContextConfiguration ligeramente diferente: una forma rápida y sucia de hacerlo podría ser agregar una anotación de @ActiveProfiles a la clase de prueba, de esta manera Spring se verá obligada a almacenar en caché el contexto con una nueva clave O definir un contexto ficticio con su existente configuración como importaciones

2. Un truco, pero JUnit 4.11+ permite cierto nivel de control sobre el orden del método de prueba, es posible tener un método de prueba justo antes de su método de prueba objetivo y tener el método de prueba ficticio anotado con @DirtiesContext , de esta manera cuando se llama a su método objetivo se creará un nuevo contexto.