Anotaciones de prueba

@ContextConfiguration
class MyIntegrationTests {
    companion object {
        @JvmStatic
        val server: MyExternalServer = // ...
        @DynamicPropertySource
        @JvmStatic
        fun dynamicProperties(registry: DynamicPropertyRegistry) { 
            registry.add("server.port", server::getPort)
        }
    }
    // pruebas...
}

1. Marque el método static con la anotación @DynamicPropertySource.
2. Aceptamos DynamicPropertyRegistry como argumento.
3. Registramos la propiedad dinámica server.port, que se recibirá del servidor en diferido.

Para obtener más información, consulte "Configuración de contexto utilizando fuentes de propiedades dinámicas".

@DirtiesContext

La anotación @DirtiesContext indica que el subyacente ApplicationContext es de Spring y se "contaminó" durante la ejecución de la prueba (es decir, la prueba lo cambió o lo corrompió de alguna manera, por ejemplo, cambiando el estado de un bean singleton) y debe cerrarse. Si el contexto de una aplicación está marcado como sucio, se elimina de la memoria caché del sistema de prueba y se cierra. Como resultado, el contenedor Spring base se reconstruye para cualquier prueba posterior que necesariamente requiera un contexto con los mismos metadatos de configuración.

La anotación @DirtiesContext se puede usar tanto en la clase nivel y en el nivel de método dentro de una sola clase o jerarquía de clases. En tales escenarios, el ApplicationContext se marca como sucio antes o después de cualquier método anotado, y antes o después de la clase de prueba actual, dependiendo del methodMode y del classMode configurados.

Los siguientes ejemplos explican cuándo el contexto puede "contaminarse" en varios escenarios de configuración:

• Antes de la clase de prueba actual, si declarado para una clase usando el modo de clase establecido en BEFORE_CLASS.

  Java

  
  @DirtiesContext(classMode = BEFORE_CLASS) 
  class FreshContextTests {
      // algunas pruebas que requieren un nuevo contenedor Spring
  } 

  1. Contexto "sucio" antes de la clase de prueba actual.
  Kotlin

  
  @DirtiesContext(classMode = BEFORE_CLASS ) 
  class FreshContextTests {
      // algunas pruebas que requieren un nuevo contenedor Spring
  }

  1. El contexto "sucio" está antes de la clase de prueba actual.

• Después de la clase de prueba actual clase de prueba, si se declara para una clase cuyo modo de clase está establecido en AFTER_CLASS (es decir, modo de clase predeterminado).

  Java

  
  @DirtiesContext 
  class ContextDirtyingTests {
      // algunas pruebas que contaminan el contenedor Spring
  } 

  1. Contexto "sucio" después de la prueba actual class.
  Kotlin

  
  @DirtiesContext 
  class ContextDirtyingTests {
      // algunas pruebas que hacen que el contenedor Spring se ensucie
  }

  1. Contexto "sucio" después la clase de prueba actual.

• Antes de cada método de prueba en la clase de prueba actual, si se declara para una clase cuyo modo de clase está establecido en BEFORE_EACH_TEST_METHOD.

  Java

  
  @DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) 
  class FreshContextTests {
      // algunas pruebas que requieren un nuevo contenedor Spring
  }

  1. Contexto sucio antes de cada prueba método.
  Kotlin

  
  @DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) 
  class FreshContextTests {
      // algunas pruebas que requieren un nuevo contenedor Spring
  }

  1. "Sucio" contexto antes de cada método de prueba.

• Después de cada método de prueba en la clase de prueba actual, si se declara para una clase cuyo modo de clase está establecido en AFTER_EACH_TEST_METHOD.

  Java

  
  @DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
  class ContextDirtyingTests {
      // algunas pruebas que hacen que el contenedor Spring se ensucie
  }} 

  1. " Contexto "sucio" después de cada método de prueba.
  Kotlin

  
  @DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
  class ContextDirtyingTests {
      // algunas pruebas que conducen a la contaminación del contenedor Spring
  } 

  1. Contexto sucio después de cada método de prueba.

• Antes de la prueba actual, si se declara para un método cuyo modo de método está establecido en BEFORE_METHOD.

  Java

  
  @DirtiesContext(methodMode = BEFORE_METHOD) 
  @Test
  void testProcessWhichRequiresFreshAppCtx() {
      // alguna lógica que requiere un nuevo contenedor Spring
  }} 

  1. Contexto "sucio" antes del método de prueba actual.
  Kotlin

  
  @DirtiesContext(methodMode = BEFORE_METHOD) 
  @Test
  fun testProcessWhichRequiresFreshAppCtx() {
      // alguna lógica que requiere un nuevo contenedor Spring
  }

  1. Contexto "sucio" antes del método de prueba actual.

• Después de la prueba actual, si se declara en un método cuyo El modo del método se establece en AFTER_METHOD (es decir, modo de método predeterminado).

  Java

  
  @DirtiesContext 
  @Test
  void testProcessWhichDirtiesAppCtx() {
      // alguna lógica que hace que el contenedor Spring se ensucie
  }

  1. "Sucio" contexto después del método de prueba actual.
  Kotlin

  
  @DirtiesContext 
  @Test
  fun testProcessWhichDirtiesAppCtx() {
      // alguna lógica que contamina el contenedor Spring
  } 

  1. El contexto "sucio" después del método de prueba actual.

Si usa la anotación @DirtiesContext en una prueba cuya El contexto se configura como parte de una jerarquía de contexto usando la anotación @ContextHierarchy, el indicador hierarchyMode se puede usar para controlar el proceso de borrar el caché de contexto. De forma predeterminada, para borrar el caché de contexto, se utiliza un algoritmo de búsqueda exhaustivo, que afecta no solo al nivel actual, sino también a todas las demás jerarquías de contexto que tienen un contexto ancestro común con la prueba actual. Todas las instancias de ApplicationContext que están en la rama de jerarquía de contexto de ancestro común se eliminan de la caché de contexto y se cierran. Si el algoritmo de búsqueda exhaustiva es excesivo para un caso de uso particular, entonces puede especificar un algoritmo de nivel actual más simple, como se muestra en el siguiente ejemplo.

 
@ContextHierarchy({
    @ContextConfiguration("/parent-config.xml"),
    @ContextConfiguration("/child-config.xml")
})
class BaseTests {
    // cuerpo de clase...
}
class ExtendedTests extends BaseTests {
    @Test
    @DirtiesContext(hierarchyMode = CURRENT_LEVEL) 
    void test() {
        // alguna lógica que contamina el contexto secundario
    }
} 

1. Usamos el algoritmo de nivel actual.

@ContextHierarchy(
    ContextConfiguration("/parent-config.xml"),
    ContextConfiguration("/child-config.xml"))
open class BaseTests {
    // cuerpo de clase...
}
class ExtendedTests : BaseTests() {
    @Test
    @DirtiesContext (hierarchyMode = CURRENT_LEVEL) 
    fun test() {
        // alguna lógica que contamina el contexto secundario
    }
}  

1. Utilizamos el algoritmo de nivel actual.

Más información sobre los algoritmos EXHAUSTIVE y CURRENT_LEVEL consulte javadoc en "DirtiesContext.HierarchyMode".

@TestExecutionListeners

@TestExecutionListeners se utiliza para registrar oyentes para una clase de prueba específica, sus subclases y clases anidadas. Si necesita registrar un oyente globalmente, debe registrarlo a través del mecanismo de descubrimiento automático descrito en Sección de configuración TestExecutionListener.

El siguiente ejemplo muestra cómo registrar dos implementaciones de TestExecutionListener:

@ContextConfiguration
@TestExecutionListeners({CustomTestExecutionListener.class, AnotherTestExecutionListener.class}) 
class CustomTestExecutionListenerTests {
    // cuerpo de la clas...
}

1. Registrar dos implementaciones de TestExecutionListener.

@ContextConfiguration
@TestExecutionListeners(CustomTestExecutionListener::class, AnotherTestExecutionListener::class) 
class CustomTestExecutionListenerTests {
    // cuerpo de la clase...
} 

1. Registra dos implementaciones TestExecutionListener.

De forma predeterminada, la anotación @TestExecutionListeners proporciona soporte para heredar escuchas de superclases o clases adjuntas. Consulte "Configuración de clase de prueba con @anotación anidada" y javadoc mediante anotación @TestExecutionListeners para ver un ejemplo e información detallada. Si descubre que necesita volver a utilizar implementaciones estándar de TestExecutionListener, consulte la nota en "Registro de implementaciones de TestExecutionListener".

@RecordApplicationEvents

La anotación @RecordApplicationEvents es una anotación a nivel de clase, que se utiliza para indicarle al Spring TestContext Framework que registre todos los eventos de la aplicación que se publican en el ApplicationContext durante la ejecución de una sola prueba.

Se puede acceder a los eventos registrados a través de la API ApplicationEvents dentro de las pruebas.

Ver: javadoc en "Eventos de aplicación" y "@RecordApplicationEvents Annotations" para ver un ejemplo y obtenga más detalles.

@Commit

La anotación @Commit especifica que la transacción para un método de prueba transaccional debe confirmarse después de que se complete el método de prueba. Puede utilizar la anotación @Commit como reemplazo directo de la anotación @Rollback(false) para hacer que el código sea más explícito. De manera similar a la anotación @Rollback, la anotación @Commit también se puede declarar como una anotación a nivel de clase o método.

El siguiente ejemplo muestra cómo utilizar la @Commit anotación de:

@Commit 
@Test
void testProcessWithoutRollback() {
    // ...
} 

1. Corregir el resultado de la prueba en la base de datos.

@Commit 
@Test
fun testProcessWithoutRollback() {
    // ...
} 

1. Reparar el resultado de la prueba en la base de datos.

@Rollback

La anotación @Rollback especifica si la transacción para un método de prueba transaccional debe revertirse una vez que se completa el método de prueba. . Si se establece en true, la transacción se revierte. De lo contrario, la transacción se confirma (consulte también @Commit ). La reversión para pruebas de integración en Spring TestContext Framework tiene el valor predeterminado true, incluso si la anotación @Rollback no se declara explícitamente.

Si la anotación es @Rollback se declara como una anotación a nivel de clase, luego define la semántica de reversión predeterminada para todos los métodos de prueba en la jerarquía de clases de prueba. Si la anotación @Rollback se declara a nivel de método, define la semántica de reversión para un método de prueba particular, anulando potencialmente la semántica de @Rollback o @Commit la anotación en el nivel de clase.

En el siguiente ejemplo, el resultado del método de prueba no se revierte (es decir, el resultado se confirma en la base de datos):

@Rollback(false ) 
@Test
void testProcessWithoutRollback() {
    // ...
}  

1. No revertimos el resultado.

@Rollback(false) 
@Test
fun testProcessWithoutRollback() {
    // ...
} 

1. No revertimos el resultado.

@BeforeTransaction

La anotación @BeforeTransaction indica que el método void anotado el debe ejecutarse antes de que comience la transacción en el caso de métodos de prueba configurados para ejecutarse dentro una transacción a través de la anotación @Transactional de Spring. Los métodos marcados con la anotación @BeforeTransaction son opcionales, deben ser public y se pueden declarar en métodos de interfaz con la implementación predeterminada basada en Java 8.

El siguiente ejemplo muestra cómo utilizar la anotación @BeforeTransaction:

@BeforeTransaction 
void beforeTransaction() {
    // lógica que debe ejecutarse antes de que comience la transacción
}

1. Ejecute este método antes de la transacción.

@BeforeTransaction 
fun beforeTransaction() {
    // lógica que debe ejecutarse antes de que comience la transacción
}

1. Ejecute este método antes de la transacción.

@AfterTransaction

La anotación @AfterTransaction especifica que el método anotado void debe ejecutarse después de que se complete la transacción en el caso de métodos de prueba configurados para ejecutarse dentro de una transacción a través de anotación @Transactional de Spring. Los métodos marcados con la anotación @AfterTransaction no necesitan ser public y pueden declararse en métodos de interfaz con la implementación predeterminada basada en Java 8.

@AfterTransaction 
void afterTransaction() {
    // lógica que se ejecutará después de que se complete la transacción
}

1. Ejecutamos este método después de la transacción.

AfterTransaction 
fun afterTransaction() {
    // lógica que se ejecutará después de que se complete la transacción
}

1. Ejecutamos este método después de la transacción.

@Sql

La anotación @Sql se utiliza para anotar una clase de prueba o un método de prueba para configurar los scripts SQL que se ejecutarán en una base de datos determinada durante las pruebas de integración. El siguiente ejemplo muestra cómo usarlo:

@Test
@Sql({"/test-schema.sql", "/test-user-data.sql"}) 
void userTest() {
    // ejecuta código que utiliza circuito de prueba y datos de prueba
}

1. Ejecute dos scripts para esta prueba.

@Test
@Sql("/test-schema.sql", "/test-user-data.sql") 
fun userTest() {
    // ejecuta código que utiliza circuito de prueba y datos de prueba
}

1. Ejecute dos scripts para esta prueba.

Para obtener más información, consulte "Ejecución declarativa de scripts SQL utilizando anotaciones @Sql.

@SqlConfig

@SqlConfig define metadatos que se utilizan para determinar cómo analizar y ejecutar scripts SQL configurados con la anotación @Sql. El siguiente ejemplo muestra cómo usarlo:

@Prueba
@Sql(
    scripts = "/test-user-data.sql",
    config = @SqlConfig(commentPrefix = "`", separator = "@@") 
)
anular prueba de usuario() {
    // ejecutar código que utiliza datos de prueba
}

1. Establezca el prefijo y el delimitador del comentario en scripts SQL.

@Prueba
@Sql("/test-user-data.sql", config = SqlConfig(commentPrefix = "`", separator = "@@")) 
            prueba de usuario divertida() {
    // ejecutar código que utiliza datos de prueba
}
            

1. Establezca el prefijo y el delimitador del comentario en scripts SQL.

@SqlMergeMode

La anotación @SqlMergeMode se utiliza para anotar una clase de prueba o un método de prueba para configurar las declaraciones de anotación @Sql a nivel de método que se fusionarán con @Sql declaraciones de anotaciones dea nivel de clase. Si la anotación @SqlMergeMode no se ha declarado para una clase de prueba o método de prueba, entonces se utilizará el modo de combinación predeterminado OVERRIDE. En el modo OVERRIDE, las declaraciones de anotación @Sql a nivel de método anularán efectivamente las declaraciones de anotación @Sql a nivel de clase.

Tenga en cuenta que declarar la anotación @SqlMergeMode en el nivel de método anula la declaración en el nivel de clase.

El siguiente ejemplo muestra cómo utilizar la anotación @SqlMergeMode a nivel de clase.

@SpringJUnitConfig(TestConfig.class)
@Sql("/test-schema.sql")
@SqlMergeMode(FUSIONAR) 
clase Pruebas de usuario {
    @Prueba
    @Sql("/usuario-test-data-001.sql")
    anular el perfil de usuario estándar() {
        // ejecuta código que utiliza el conjunto de datos de prueba 001
    }
}

1. Establezca el modo de fusión de anotaciones @Sql en MERGE para todos los métodos de prueba de la clase.

@SpringJUnitConfig(TestConfig::clase)
@Sql("/test-schema.sql")
@SqlMergeMode(FUSIONAR) 
clase Pruebas de usuario {
    @Prueba
    @Sql("/datos-de-prueba-de-usuario-001.sql")
    divertido perfil de usuario estándar() {
        // ejecuta código que utiliza el conjunto de datos de prueba 001
    }
}
        

1. Establezca el modo de fusión de anotaciones @Sql en MERGE para todos los métodos de prueba de la clase.

El siguiente ejemplo muestra cómo utilizar la anotación @SqlMergeMode a nivel de método.

@SpringJUnitConfig(TestConfig.class)
@Sql("/test-schema.sql")
clase Pruebas de usuario {
    @Prueba
    @Sql("/usuario-test-data-001.sql")
    @SqlMergeMode(FUSIONAR) 
    anular el perfil de usuario estándar() {
        // ejecuta código que utiliza el conjunto de datos de prueba 001
    }
}

1. Establezca el modo de fusión de anotaciones @Sql en MERGE para un método de prueba específico.

@SpringJUnitConfig(TestConfig::clase)
@Sql("/test-schema.sql")
clase Pruebas de usuario {
    @Prueba
    @Sql("/usuario-test-data-001.sql")
    @SqlMergeMode(FUSIONAR) 
    divertido perfil de usuario estándar() {
        // ejecuta código que utiliza el conjunto de datos de prueba 001
    }
}
        

1. Establezca el modo de fusión de anotaciones @Sql en MERGE para un método de prueba específico.

@SqlGroup

@SqlGroup es una anotación de contenedor que combina múltiples anotaciones @Sql. Puede usar la anotación @SqlGroup para declarar múltiples anotaciones @Sql anidadas, o usarla en combinación con el soporte de anotación duplicada de Java 8 donde anotación de @Sql se puede declarar varias veces para la misma clase o método, generando implícitamente esta anotación de contenedor. El siguiente ejemplo muestra cómo declarar un grupo SQL:

@Prueba
@SqlGroup({ 
    @Sql(scripts = "/test-schema.sql", config = @SqlConfig(commentPrefix = "`")),
    @Sql("/prueba-datos-de-usuario.sql")
})
anular prueba de usuario() {
    // ejecutar código usando circuito de prueba y datos de prueba
}

1. Declarar un grupo de scripts SQL.

@Prueba
@SqlGroup( 
    Sql("/test-schema.sql", config = SqlConfig(commentPrefix = "`")),
    Sql("/prueba-datos-de-usuario.sql"))
prueba de usuario divertida() {
    // ejecutar código usando circuito de prueba y datos de prueba
}
        

1. Declarar un grupo de scripts SQL.