Spring Framework contiene el siguiente conjunto de anotaciones específicas de Spring que se pueden usar en sus pruebas unitarias y de integración junto con el marco TestContext. Consulte el javadoc correspondiente para obtener más información, incluidos valores de atributos predeterminados, alias de atributos y más.
Existen las siguientes anotaciones para realizar pruebas en Spring:
@BootstrapWith
@BootstrapWith
es una anotación de nivel de clase que se puede utilizar para configurar cómo se
inicia Spring TestContext Framework. En particular, puede utilizar @BootstrapWith
para especificar un
TestContextBootstrapper
especial. Para obtener más información, consulte Cómo
iniciar el marco TestContext.
@ContextConfiguration
La anotación @ContextConfiguration
define metadatos a nivel de clase que se utilizan para
determinar cómo cargar y configurar ApplicationContext
para las pruebas de integración.
Específicamente, @ContextConfiguration declara las ubicaciones
de los recursos del contexto de la
aplicación o las classes
de los componentes utilizados para cargar el contexto.
Las ubicaciones
de los recursos suelen ser archivos de configuración XML o Groovy. scripts ubicados en el classpath, mientras
que las clases de componentes suelen ser clases con la anotación @Configuration
. Sin embargo, las
ubicaciones de recursos también pueden hacer referencia a archivos y scripts en el sistema de archivos, y las
clases de componentes pueden ser clases anotadas con @Component
, @Service
, etc. Para
obtener más información, consulte "Clases
de componentes".
El siguiente ejemplo muestra la anotación @ContextConfiguration
que hace referencia a un archivo
XML:
@ContextConfiguration("/test-config.xml")
class XmlApplicationContextTests {
// cuerpo de clase...
}
- Refiriéndose al archivo XML.
@ContextConfiguration("/test-config.xml")
class XmlApplicationContextTests {
// @ContextConfiguration("/test-config.xml")
class XmlApplicationContextTests {
// class body...
}
- Refiriéndose al archivo XML.
El siguiente ejemplo muestra @ContextConfiguration
anotación que hace referencia a la clase:
@ContextConfiguration(classes = TestConfig.class)
class ConfigClassApplicationContextTests {
// cuerpo de la clase...
}
- Referencia a la clase.
@ContextConfiguration(classes = [TestConfig::class])
class ConfigClassApplicationContextTests {
// cuerpo de la clase...
}
- Hacer referencia a una clase.
Alternativamente, o además de declarar una búsqueda de ubicaciones de recursos o clases de componentes,
puede usar @ContextConfiguration
para declarar las clases
ApplicationContextInitializer
. El siguiente ejemplo muestra un caso de este tipo:
@ContextConfiguration(initializers = CustomContextInitializer.class)
class ContextInitializerTests {
// cuerpo de la clase...
}
- Declarar la clase-inicializador.
@ContextConfiguration(initializers = [CustomContextInitializer::class])
class ContextInitializerTests {
// cuerpo de la clase...
}
- Declarar una clase inicializadora.
También puede utilizar la anotación @ContextConfiguration
para declarar la estrategia ContextLoader
.
Sin embargo, tenga en cuenta que a menudo no es necesario configurar explícitamente el cargador, ya que el
cargador predeterminado admite initializers
y recursos locations
o
classes
de componentes.
El siguiente ejemplo utiliza tanto la ubicación como el cargador:
@ContextConfiguration(locations = "/test-context.xml", loader = CustomContextLoader.class)
class CustomLoaderXmlApplicationContextTests {
// cuerpo de la clase...
}
- Configure tanto la ubicación como el gestor de arranque personalizado.
@ContextConfiguration("/test-context.xml", loader = CustomContextLoader::class)
class CustomLoaderXmlApplicationContextTests {
// cuerpo de la clase..
}
- Configure tanto la ubicación como el gestor de arranque personalizado.
@ContextConfiguration
proporciona soporte para heredar
ubicaciones de recursos o clases de configuración, así como inicializadores de contexto declarados por
superclases o clases adjuntas.
Ver sección dedicada a la gestión
del contexto, configuraciones
de clases de prueba con la anotación @Nested
y javadocs con la anotación @ContextConfiguration
para más detalles.
@WebAppConfiguration
@WebAppConfiguration
es una anotación a nivel de clase que se puede utilizar para declarar que es que se
está cargando
ApplicationContext
para una prueba de integración debe ser WebApplicationContext
.
La sola presencia de la anotación @WebAppConfiguration
en la clase de prueba garantiza que la
prueba cargará WebApplicationContext
usando el valor predeterminado
"file:src/main/webapp"
para la ruta a la raíz de la aplicación web (es decir, la ruta principal del recurso). La ruta de recurso
principal se utiliza detrás de escena para crear un MockServletContext
que sirve como
ServletContext para la prueba WebApplicationContext
.
El siguiente ejemplo muestra cómo utilice la anotación @WebAppConfiguration
:
@ContextConfiguration
@WebAppConfiguration
class WebAppTests {
// cuerpo de clase...
}
- Anotación
@WebAppConfiguration
.
@ContextConfiguration
@WebAppConfiguration
class WebAppTests {
// cuerpo de clase...
}
- Anotación
@WebAppConfiguration
.
Para anular el valor predeterminado, puede establecer una ruta de recurso principal diferente utilizando un
atributo value
explícito. Se admiten los prefijos de recursos classpath:
y
file:
. Si no se especifica un prefijo de recurso, se supone que la ruta es un recurso del sistema
de archivos. El siguiente ejemplo muestra cómo configurar un recurso classpath:
@ContextConfiguration
@WebAppConfiguration("classpath:test-web-resources")
class WebAppTests {
// cuerpo de clase...
}
- Establecer un recurso de classpath.
@ContextConfiguration
@WebAppConfiguration("classpath:test-web-resources")
class WebAppTests {
// cuerpo de clase...
}
- Establezca un recurso de classpath.
Tenga en cuenta que la anotación @WebAppConfiguration
debe usarse en combinación con la
anotación de @ContextConfiguration
dentro de una clase de prueba, o dentro de una jerarquía de
clases de prueba. Para obtener más información, consulte la anotación de javadoc @WebAppConfiguration
.
@ContextHierarchy
@ContextHierarchy
es una anotación a nivel de clase que se utiliza para definir una jerarquía de
instancias ApplicationContext
para pruebas de integración. La anotación
@ContextHierarchy
debe declararse utilizando una lista de una o más instancias de la anotación
@ContextConfiguration
, cada una de las cuales define un nivel en la jerarquía de contexto. Los
siguientes ejemplos muestran el uso de la anotación @ContextHierarchy
dentro de una única clase de
prueba (la anotación @ContextHierarchy
también se puede usar dentro de una jerarquía de clases de
prueba):
@ContextHierarchy({
@ContextConfiguration("/parent-config.xml"),
@ContextConfiguration("/child-config.xml")
})
class ContextHierarchyTests {
// cuerpo de la clase...
}
@ContextHierarchy(
ContextConfiguration("/parent-config.xml"),
ContextConfiguration( "/child-config.xml"))
class ContextHierarchyTests {
// cuerpo de la clase...
}
@WebAppConfiguration
@ContextHierarchy({
@ContextConfiguration(classes = AppConfig.class),
@ContextConfiguration(classes = WebConfig.class)
})
class WebIntegrationTests {
// cuerpo de la clase...
}
@WebAppConfiguration
@ContextHierarchy(
ContextConfiguration(classes = [AppConfig::class]),
ContextConfiguration(classes = [WebConfig::class]))
class WebIntegrationTests {
// cuerpo de la clase...
}
Si desea fusionar o anular la configuración para un nivel determinado del contexto jerarquía en la jerarquía de
clases de prueba, debe darle explícitamente un nombre a este nivel pasando el mismo valor al atributo
name
en la anotación @ContextConfiguration
para cada nivel correspondiente de la
clase jerarquía. Para obtener más ejemplos, consulte "Context
Hierarchies" y javadoc de anotación
@ContextHierarchy
.
@ActiveProfiles
@ActiveProfiles
es una anotación a nivel de clase que se utiliza para declarar qué perfiles de
definición de bean deben estar activos cuando cargando ApplicationContext
para una prueba de
integración.
El siguiente ejemplo muestra que el perfil dev
debe estar activo:
@ContextConfiguration
@ActiveProfiles("dev")
class DeveloperTests {
// cuerpo de clase...
}
- Indica que el perfil
dev
debe estar activo.
@ContextConfiguration
@ActiveProfiles("dev")
class DeveloperTests {
// cuerpo de clase...
}
- Indica que el perfil es
dev
debe estar activo.
El siguiente ejemplo muestra que tanto el perfil dev
como el integration
deben estar
activos:
@ContextConfiguration
@ActiveProfiles({"dev", "integration"})
class DeveloperIntegrationTests {
// cuerpo de clase...
}
- Indicamos que el Los perfiles
dev
eintegration
deben estar activos.
@ContextConfiguration
@ActiveProfiles(["dev", "integration"])
class DeveloperIntegrationTests {
// cuerpo de clase...
}
- Indique que los perfiles
dev
eintegration
deben estar activos.
@ActiveProfiles
proporciona soporte para
heredar perfiles de definición de beans activos declarados por superclases y clases adjuntas predeterminadas.
También puede resolver mediante programación perfiles de definición de beans activos implementando un ActiveProfilesResolver
y registrarlo usando el atributo resolver
de la
anotación @ActiveProfiles
.
Ver: secciones "Configuración
de contexto utilizando perfiles de entorno", "Configuración
de una clase de prueba con la anotación @Nested"
, así como la anotación javadoc @ActiveProfiles
para ejemplos e información más detallada.
@TestPropertySource
@TestPropertySource
– es una anotación a nivel de clase que se puede utilizar para configurar las
ubicaciones de los archivos de propiedades y las propiedades en línea que se agregarán al paquete PropertySources
en el Environment
para ApplicationContext,
cargado para una prueba de integración.
El siguiente ejemplo muestra cómo declarar un archivo de propiedades desde el classpath:
@ContextConfiguration
@TestPropertySource("/test.properties")
class MyIntegrationTests {
// cuerpo de clase...
}
- Obtener propiedades de
test.properties
en el classpath raíz.
@ContextConfiguration
@TestPropertySource("/test.properties")
class MyIntegrationTests {
// cuerpo de clase...
}
- Obtener propiedades de
test.properties
en la raíz del classpath.
El siguiente ejemplo muestra cómo declarar propiedades en línea:
@ContextConfiguration
@TestPropertySource(properties = { "timezone = GMT", "port: 4242" })
class MyIntegrationTests {
// cuerpo de clase...
}
- Declare las propiedades
timezone
yport
.
@ContextConfiguration
@TestPropertySource(properties = ["timezone = GMT", "port: 4242"])
class MyIntegrationTests {
// cuerpo de clase...
}
- Declare las propiedades
timezone
yport
.
Para ejemplos y más información, consulte "Configuración de contexto utilizando fuentes de propiedades de prueba".
@DynamicPropertySource
@DynamicPropertySource
es una anotación a nivel de método que se puede utilizar para registrar
propiedades dinámicas agregadas a PropertySources
paquete en Environment
para
ApplicationContext
cargado para la prueba de integración. Las propiedades dinámicas son útiles si los
valores de las propiedades no se conocen de antemano; por ejemplo, si las propiedades son administradas por un
recurso externo, como es el caso de un contenedor administrado por el proyecto Testcontainers.
El siguiente ejemplo muestra cómo registrar una propiedad dinámica:
@ContextConfiguration
class MyIntegrationTests {
static MyExternalServer server = // ...
@DynamicPropertySource
static void dynamicProperties(DynamicPropertyRegistry registry) {
registry.add("server.port", server::getPort);
}
// pruebas...
}
- Marque el método
static
con la anotación@DynamicPropertySource
. - Aceptar
DynamicPropertyRegistry
como argumento. - Registre la propiedad dinámica
server.port
, que se recibirá del servidor más tarde.
@ContextConfiguration
class MyIntegrationTests {
companion object {
@JvmStatic
val server: MyExternalServer = // ...
@DynamicPropertySource
@JvmStatic
fun dynamicProperties(registry: DynamicPropertyRegistry) {
registry.add("server.port", server::getPort)
}
}
// pruebas...
}
- Marque el método
static
con la anotación@DynamicPropertySource
. - Aceptamos
DynamicPropertyRegistry
como argumento. - 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 }
- Contexto "sucio" antes de la clase de prueba actual.
Kotlin@DirtiesContext(classMode = BEFORE_CLASS ) class FreshContextTests { // algunas pruebas que requieren un nuevo contenedor Spring }
- 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 }
- Contexto "sucio" después de la prueba actual class.
Kotlin@DirtiesContext class ContextDirtyingTests { // algunas pruebas que hacen que el contenedor Spring se ensucie }
- 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 }
- 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 }
- "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 }}
- " 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 }
- 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 }}
- 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 }
- 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 }
- "Sucio" contexto después del método de prueba actual.
Kotlin@DirtiesContext @Test fun testProcessWhichDirtiesAppCtx() { // alguna lógica que contamina el contenedor Spring }
- 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
}
}
- 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
}
}
- 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...
}
- Registrar dos implementaciones de
TestExecutionListener
.
@ContextConfiguration
@TestExecutionListeners(CustomTestExecutionListener::class, AnotherTestExecutionListener::class)
class CustomTestExecutionListenerTests {
// cuerpo de la clase...
}
- 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() {
// ...
}
- Corregir el resultado de la prueba en la base de datos.
@Commit
@Test
fun testProcessWithoutRollback() {
// ...
}
- 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() {
// ...
}
- No revertimos el resultado.
@Rollback(false)
@Test
fun testProcessWithoutRollback() {
// ...
}
- 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
}
- Ejecute este método antes de la transacción.
@BeforeTransaction
fun beforeTransaction() {
// lógica que debe ejecutarse antes de que comience la transacción
}
- 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
}
- 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
}
- 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
}
- 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
}
- Ejecute dos scripts para esta prueba.
Para obtener más información, consulte "Ejecución declarativa de scripts SQL utilizando anotaciones @Sql.
@SqlConfig
La anotación @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
}
- 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
}
- 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
}
}
- Establezca el modo de fusión de anotaciones
@Sql
enMERGE
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
}
}
- Establezca el modo de fusión de anotaciones
@Sql
enMERGE
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
}
}
- Establezca el modo de fusión de anotaciones
@Sql
enMERGE
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
}
}
- Establezca el modo de fusión de anotaciones
@Sql
enMERGE
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
}
- 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
}
- Declarar un grupo de scripts SQL.