Spring Framework содержит следующий набор аннотаций, специфичных для Spring, которые можно использовать в ваших модульных и интеграционных тестах в сочетании с фреймворком TestContext. Смотрите соответствующий javadoc для получения дополнительной информации, включая значения атрибутов по умолчанию, псевдонимы атрибутов и другие сведения.

Для тестирования в Spring существуют следующие аннотации:

@BootstrapWith

@BootstrapWith – это аннотация на уровне класса, которую можно использовать для конфигурирования способа начальной загрузки Spring TestContext Framework. В частности, можно использовать @BootstrapWith для задания специального TestContextBootstrapper. Более подробную информацию см. в разделе, посвященном начальной загрузке фреймворка TestContext.

@ContextConfiguration

Аннотация @ContextConfiguration определяет метаданные на уровне класса, которые используются для определения того, как загружать и конфигурировать ApplicationContext для интеграционных тестов. В частности, @ContextConfiguration объявляет locations ресурсов контекста приложения или компонентные classes, используемые для загрузки контекста.

Местоположения ресурсов обычно представляет собой XML-файлы конфигурации или скрипты Groovy, расположенные в classpath, в то время как компонентные классы обычно являются классами с аннотацией @Configuration. Однако местоположения ресурсов могут также ссылаться на файлы и скрипты в файловой системе, а компонентные классы могут быть классами, аннотированными @Component, @Service и так далее. Более подробную информацию см. в разделе "Компонентные классы".

В следующем примере показана аннотация @ContextConfiguration, которая ссылается на XML-файл:

Java
@ContextConfiguration("/test-config.xml") 
class XmlApplicationContextTests {
    // тело класса...
}
  1. Ссылаемся на XML-файл.
Kotlin
@ContextConfiguration("/test-config.xml") 
class XmlApplicationContextTests {
    // тело класса...
}
  1. Ссылаемся на XML-файл.

В следующем примере показана аннотация @ContextConfiguration, которая ссылается на класс:

Java
@ContextConfiguration(classes = TestConfig.class) 
class ConfigClassApplicationContextTests {
    // тело класса...
}
  1. Ссылаемся на класс.
Kotlin
@ContextConfiguration(classes = [TestConfig::class]) 
class ConfigClassApplicationContextTests {
    // тело класса...
}
  1. Ссылаемся на класс.

В качестве альтернативы или в дополнение к объявлению поиска местоположений ресурсов или классов компонентов, можно использовать @ContextConfiguration для объявления классов ApplicationContextInitializer. В следующем примере показан такой случай:

Java
@ContextConfiguration(initializers = CustomContextInitializer.class) 
class ContextInitializerTests {
    // тело класса...
}
  1. Объявляем класс-инициализатор.
Kotlin
@ContextConfiguration(initializers = [CustomContextInitializer::class]) 
class ContextInitializerTests {
    // тело класса...
}
  1. Объявляем класс-инициализатор.

Также можно использовать аннотацию @ContextConfiguration для объявления стратегии ContextLoader. Обратите внимание, однако, что зачастую не требуется явно конфигурировать загрузчик, поскольку загрузчик по умолчанию поддерживает initializers и либо locations ресурсов, либо компонентные classes.

В следующем примере используется как местоположение, так и загрузчик:

Java
@ContextConfiguration(locations = "/test-context.xml", loader = CustomContextLoader.class) 
class CustomLoaderXmlApplicationContextTests {
    // тело класса...
}
  1. Конфигурируем как местоположение, так и кастомный загрузчик.
Kotlin
@ContextConfiguration("/test-context.xml", loader = CustomContextLoader::class) 
class CustomLoaderXmlApplicationContextTests {
    // тело класса...
}
  1. Конфигурируем как местоположение, так и кастомный загрузчик.
@ContextConfiguration обеспечивает поддержку наследования местоположений ресурсов или конфигурационных классов, а также инициализаторов контекста, которые объявляются суперклассами или объемлющими классами.

См. раздел посвященный управлению контекстом, конфигурации тестового класса с аннотацией @Nested и javadocs по аннотации @ContextConfiguration для получения более подробных сведений.

@WebAppConfiguration

@WebAppConfiguration – это аннотация на уровне класса, которую можно использовать, чтобы объявить, что загружаемым ApplicationContext для интеграционного теста должен быть WebApplicationContext. Само наличие аннотации @WebAppConfiguration в тестовом классе обеспечивает, что для теста будет загружен WebApplicationContext с использованием значения по умолчанию "file:src/main/webapp" для пути к корню веб-приложения (то есть для основного пути ресурсов). Основной путь ресурсов используется "за кулисами" для создания MockServletContext, который служит в качестве ServletContext для WebApplicationContext теста.

В следующем примере показано, как использовать аннотацию @WebAppConfiguration:

Java
@ContextConfiguration
@WebAppConfiguration 
class WebAppTests {
    // тело класса...
}
  1. Аннотация @WebAppConfiguration.
Kotlin
@ContextConfiguration
@WebAppConfiguration 
class WebAppTests {
    // тело класса...
}
  1. Аннотация @WebAppConfiguration.

Чтобы переопределить значение по умолчанию, можно задать другой основной путь к ресурсам с помощью явного атрибута value. Поддерживаются префиксы ресурсов classpath: и file:. Если префикс ресурса не задан, предполагается, что путём является ресурс файловой системы. В следующем примере показано, как задать ресурс classpath:

Java
@ContextConfiguration
@WebAppConfiguration("classpath:test-web-resources") 
class WebAppTests {
    // тело класса...
}
Java-университет
  1. Задание ресурса classpath.
Kotlin
@ContextConfiguration
@WebAppConfiguration("classpath:test-web-resources") 
class WebAppTests {
    // тело класса...
}
  1. Задание ресурса classpath.

Обратите внимание, что аннотацию @WebAppConfiguration необходимо использовать либо в сочетании с аннотацией @ContextConfiguration в рамках одного тестового класса, либо в рамках иерархии тестовых классов. Более подробную информацию см. в javadoc по аннотации @WebAppConfiguration.

@ContextHierarchy

@ContextHierarchy – это аннотация на уровне класса, которая используется для определения иерархии экземпляров ApplicationContext для интеграционных тестов. Аннотацию @ContextHierarchy необходимо объявлять с использованием списка из одного или нескольких экземпляров аннотации @ContextConfiguration, каждый из которых определяет уровень в иерархии контекста. В следующих примерах показано использование аннотации @ContextHierarchy в рамках одного тестового класса (аннотацию @ContextHierarchy также можно использовать в рамках иерархии тестовых классов):

Java
@ContextHierarchy({
    @ContextConfiguration("/parent-config.xml"),
    @ContextConfiguration("/child-config.xml")
})
class ContextHierarchyTests {
    // тело класса...
}
Kotlin
@ContextHierarchy(
    ContextConfiguration("/parent-config.xml"),
    ContextConfiguration("/child-config.xml"))
class ContextHierarchyTests {
    // тело класса...
}
Java
@WebAppConfiguration
@ContextHierarchy({
    @ContextConfiguration(classes = AppConfig.class),
    @ContextConfiguration(classes = WebConfig.class)
})
class WebIntegrationTests {
    // тело класса...
}
Kotlin
@WebAppConfiguration
@ContextHierarchy(
        ContextConfiguration(classes = [AppConfig::class]),
        ContextConfiguration(classes = [WebConfig::class]))
class WebIntegrationTests {
    // тело класса...
}

Если требуется объединить или переопределить конфигурацию для данного уровня иерархии контекста в иерархии тестовых классов, то необходимо явным образом присвоить этому уровню имя, передав одинаковое значение атрибуту name в аннотации @ContextConfiguration для каждого соответствующего уровня иерархии классов. Дополнительные примеры см. в разделе "Иерархии контекстов" и в javadoc по аннотации @ContextHierarchy.

@ActiveProfiles

@ActiveProfiles – это аннотация на уровне класса, которая используется для объявления того, какие профили определения бинов должны быть активны при загрузке ApplicationContext для интеграционного теста.

В следующем примере показано, что профиль dev должен быть активным:

Java
@ContextConfiguration
@ActiveProfiles("dev") 
class DeveloperTests {
    // тело класса...
}
  1. Указываем, что профиль dev должен быть активным.
Kotlin
@ContextConfiguration
@ActiveProfiles("dev") 
class DeveloperTests {
    // тело класса...
}
  1. Указываем, что профиль dev должен быть активным.

В следующем примере показано, что оба профиля – dev и integration – должны быть активны:

Java
@ContextConfiguration
@ActiveProfiles({"dev", "integration"}) 
class DeveloperIntegrationTests {
    // тело класса...
}
  1. Указываем, что профили dev и integration должны быть активны.
Kotlin
@ContextConfiguration
@ActiveProfiles(["dev", "integration"]) 
class DeveloperIntegrationTests {
    // тело класса...
}
  1. Указываем, что профили dev и integration должны быть активны.
Аннотация @ActiveProfiles обеспечивает поддержку наследования активных профилей определения бинов, объявленных суперклассами и объемлющими классами по умолчанию. Вы также можете программно разрешать профили определения активных бинов, реализовав кастомный ActiveProfilesResolver и зарегистрировав его с помощью атрибута resolver аннотации @ActiveProfiles.

См. разделы "Конфигурация контекста с использованием профилей окружения", "Конфигурация тестового класса с аннотацией @Nested", а также javadoc по аннотации @ActiveProfiles для ознакомления с примерами и получения более подробной информации.

@TestPropertySource

@TestPropertySource – это аннотация на уровне класса, которую можно использовать для конфигурирования местоположений файлов свойств и встраиваемых свойств, которые будут добавлены в комплект PropertySources в Environment для ApplicationContext, загружаемого для интеграционного теста.

В следующем примере показано, как объявлять файл свойств из classpath:

Java
@ContextConfiguration
@TestPropertySource("/test.properties") 
class MyIntegrationTests {
    // тело класса...
}
  1. Получаем свойства из test.properties в корне classpath.
Kotlin
@ContextConfiguration
@TestPropertySource("/test.properties") 
class MyIntegrationTests {
    // тело класса...
}
  1. Получаем свойства из test.properties в корне classpath.

В следующем примере показано, как объявлять встраиваемые свойства:

Java
@ContextConfiguration
@TestPropertySource(properties = { "timezone = GMT", "port: 4242" }) 
class MyIntegrationTests {
    // тело класса...
}
  1. Объявляем свойства timezone и port.
Kotlin
@ContextConfiguration
@TestPropertySource(properties = ["timezone = GMT", "port: 4242"]) 
class MyIntegrationTests {
    // тело класса...
}
  1. Объявляем свойства timezone и port.

Примеры и дополнительные сведения см. в разделе "Конфигурация контекста с использованием источников тестовых свойств".

@DynamicPropertySource

@DynamicPropertySource – это аннотация на уровне метода, которую можно использовать для регистрации динамических свойств, добавляемых в комплект PropertySources в Environment для ApplicationContext, загружаемого для интеграционного теста. Динамические свойства полезны, если значения свойств заранее неизвестны – например, если свойствами управляет внешний ресурс, как в случае с контейнером, управляемым проектом Testcontainers.

В следующем примере показано, как зарегистрировать динамическое свойство:

Java
@ContextConfiguration
class MyIntegrationTests {
    static MyExternalServer server = // ...
    @DynamicPropertySource 
    static void dynamicProperties(DynamicPropertyRegistry registry) { 
        registry.add("server.port", server::getPort); 
    }
    // tests ...
}
  1. Помечаем static метод аннотацией @DynamicPropertySource.
  2. Принимаем в качестве аргумента DynamicPropertyRegistry.
  3. Регистрируем динамическое свойство server.port, которое будет получено с сервера отложено.
Kotlin
@ContextConfiguration
class MyIntegrationTests {
    companion object {
        @JvmStatic
        val server: MyExternalServer = // ...
        @DynamicPropertySource 
        @JvmStatic
        fun dynamicProperties(registry: DynamicPropertyRegistry) { 
            registry.add("server.port", server::getPort) 
        }
    }
    // tests ...
}
  1. Помечаем static метод аннотацией @DynamicPropertySource.
  2. Принимаем в качестве аргумента DynamicPropertyRegistry.
  3. Регистрируем динамическое свойство server.port, которое будет получено с сервера отложено.

Дополнительные сведения см. в разделе "Конфигурация контекста с использованием источников динамических свойств".

@DirtiesContext

Аннотация @DirtiesContext указывает, что базовый ApplicationContext из Spring был "загрязнен" во время выполнения теста (то есть тест изменил или испортил его каким-то образом – например, изменив состояние бина-одиночки) и его необходимо закрыть. Если контекст приложения помечен как "грязный", то он удаляется из кэша системы тестирования и закрывается. Как следствие, базовый контейнер Spring перестраивается под любой последующий тест, которому в обязательном порядке требуется контекст с теми же конфигурационными метаданными.

Аннотацию @DirtiesContext можно использовать как на уровне класса, так и на уровне метода в рамках одного класса или иерархии классов. В таких сценариях ApplicationContext помечается как "грязный" перед или после любого такого аннотированного метода, а также перед или после текущего тестового класса, в зависимости от сконфигурированных methodMode и classMode.

В следующих примерах объясняется, в каких случаях контекст может быть "загрязнен" при различных сценариев конфигурации:

  • Перед текущим тестовым классом, если объявлен для класса с помощью режима класса, установленного в BEFORE_CLASS.

    Java
    @DirtiesContext(classMode = BEFORE_CLASS) 
class FreshContextTests {
    // некоторые тесты, для которых требуется новый контейнер Spring
}
    1. "Грязный" контекст перед текущим тестовым классом.
    Kotlin
    @DirtiesContext(classMode = BEFORE_CLASS) 
class FreshContextTests {
    // некоторые тесты, для которых требуется новый контейнер Spring
}
    1. "Грязный" контекст перед текущим тестовым классом.

  • После текущего тестового класса, если объявлен для класса, режим класса которого установлен в AFTER_CLASS (т.е. режим класса по умолчанию).

    Java
    @DirtiesContext 
class ContextDirtyingTests {
    // некоторые тесты, которые приводят к загрязнению контейнера Spring
}
    1. "Грязный" контекст после текущего тестового класса.
    Kotlin
    @DirtiesContext 
class ContextDirtyingTests {
    // некоторые тесты, которые приводят к загрязнению контейнера Spring
}
    1. "Грязный" контекст после текущего тестового класса.

  • Перед каждым тестовым методом в текущем тестовом классе, если объявлен для класса, режим класса которого установлен в BEFORE_EACH_TEST_METHOD.

    Java
    @DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) 
class FreshContextTests {
    // некоторые тесты, для которых требуется новый контейнер Spring
}
    1. "Грязный" контекст перед каждым тестовым методом.
    Kotlin
    @DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) 
class FreshContextTests {
    // некоторые тесты, для которых требуется новый контейнер Spring
}
    1. "Грязный" контекст перед каждым тестовым методом.

  • После каждого тестового метода в текущем тестовом классе, если объявлен для класса, режим класса которого установлен в AFTER_EACH_TEST_METHOD.

    Java
    @DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
class ContextDirtyingTests {
    // некоторые тесты, которые приводят к загрязнению контейнера Spring
}
    1. "Грязный" контекст после каждого тестового метода.
    Kotlin
    @DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
class ContextDirtyingTests {
    // некоторые тесты, которые приводят к загрязнению контейнера Spring
}
    1. "Грязный" контекст после каждого тестового метода.

  • Перед текущим тестом, если объявлен для метода, режим метода которого установлен в BEFORE_METHOD.

    Java
    @DirtiesContext(methodMode = BEFORE_METHOD) 
@Test
void testProcessWhichRequiresFreshAppCtx() {
    // некоторая логика, которой требуется новый контейнер Spring
}
    1. "Грязный" контекст перед текущим тестовым методом.
    Kotlin
    @DirtiesContext(methodMode = BEFORE_METHOD) 
@Test
fun testProcessWhichRequiresFreshAppCtx() {
    // некоторая логика, которой требуется новый контейнер Spring
}
    1. "Грязный" контекст перед текущим тестовым методом.

  • После текущего теста, если объявлен в методе, режим метода которого установлен в AFTER_METHOD (т.е. режим метода по умолчанию).

    Java
    @DirtiesContext 
@Test
void testProcessWhichDirtiesAppCtx() {
    // некоторая логика, которая приводит к загрязнению контейнера Spring
}
    1. "Грязный" контекст после текущего тестового метода.
    Kotlin
    @DirtiesContext 
@Test
fun testProcessWhichDirtiesAppCtx() {
    // некоторая логика, которая приводит к загрязнению контейнера Spring
}
    1. "Грязный" контекст после текущего тестового метода.

Если вы используете аннотацию @DirtiesContext в тесте, контекст которого сконфигурирован как часть иерархии контекстов с помощью аннотации @ContextHierarchy, то можно использовать флаг hierarchyMode, чтобы управлять процессом очистки контекстного кэша. По умолчанию для очистки контекстного кэша используется алгоритм полного перебора вариантов, затрагивающий не только текущий уровень, но и все другие контекстные иерархии, имеющие общий с текущим тестом контекст-предок. Все экземпляры ApplicationContext, находящиеся в ветви иерархии общего контекста-предка, удаляются из контекстного кэша и закрываются. Если алгоритм полного перебора вариантов является излишним для конкретного случая использования, то можно задать более простой алгоритм текущего уровня, как показано в следующем примере.

Java
@ContextHierarchy({
    @ContextConfiguration("/parent-config.xml"),
    @ContextConfiguration("/child-config.xml")
})
class BaseTests {
    // тело класса...
}
class ExtendedTests extends BaseTests {
    @Test
    @DirtiesContext(hierarchyMode = CURRENT_LEVEL) 
    void test() {
        // некоторая логика, которая приводит к загрязнению дочернего контекста
    }
}
  1. Используем алгоритм текущего уровня.
Kotlin
@ContextHierarchy(
    ContextConfiguration("/parent-config.xml"),
    ContextConfiguration("/child-config.xml"))
open class BaseTests {
    // тело класса...
}
class ExtendedTests : BaseTests() {
    @Test
    @DirtiesContext(hierarchyMode = CURRENT_LEVEL) 
    fun test() {
        // некоторая логика, которая приводит к загрязнению дочернего контекста
    }
}
  1. Используем алгоритм текущего уровня.

Более подробную информацию об алгоритмах EXHAUSTIVE и CURRENT_LEVEL см. в javadoc по "DirtiesContext.HierarchyMode".

@TestExecutionListeners

@TestExecutionListeners используется для того, чтобы регистрировать слушателей для определенного тестового класса, его подклассов и вложенных классов. Если требуется зарегистрировать слушателя глобально, то следует регистрировать его через механизм автоматического обнаружения, описанный в разделе Конфигурация TestExecutionListener.

В следующем примере показано, как зарегистрировать две реализации TestExecutionListener:

Java
@ContextConfiguration
@TestExecutionListeners({CustomTestExecutionListener.class, AnotherTestExecutionListener.class}) 
class CustomTestExecutionListenerTests {
    // тело класса...
}
  1. Регистрируем две реализации TestExecutionListener.
Kotlin
@ContextConfiguration
@TestExecutionListeners(CustomTestExecutionListener::class, AnotherTestExecutionListener::class) 
class CustomTestExecutionListenerTests {
    // тело класса...
}
  1. Регистрируем две реализации TestExecutionListener.

По умолчанию аннотация @TestExecutionListeners обеспечивает поддержку наследования слушателей от суперклассов или объемлющих классов. См. раздел "Конфигурация тестового класса с аннотацией @Nested" и javadoc по аннотации @TestExecutionListeners для ознакомления с примером и получения подробной информации. Если вы поймете, что требуется вернуться к использованию стандартных реализаций TestExecutionListener, обратитесь к примечанию в разделе "Регистрация реализаций TestExecutionListener".

@RecordApplicationEvents

Аннотация @RecordApplicationEvents – это аннотация на уровне класса, которая используется для того, чтобы дать Spring TestContext Framework команду записывать все события приложения, которые публикуются в ApplicationContext во время выполнения единственного теста.

Доступ к записанным событиям можно получить через ApplicationEvents API в рамках тестов.

См. javadoc по "Событиям приложения" и "Аннотации @RecordApplicationEvents" для ознакомления с примером и получения дальнейших подробностей.

@Commit

Аннотация @Commit указывает, что транзакция для транзакционного метода тестирования должна быть зафиксирована после завершения метода тестирования. Можно использовать аннотацию @Commit в качестве прямой замены аннотации @Rollback(false), чтобы более явно передать суть кода. Аналогично аннотации @Rollback, аннотацию @Commit также можно объявить как аннотацию на уровне класса или метода.

В следующем примере показано, как использовать аннотацию @Commit:

Java
@Commit 
@Test
void testProcessWithoutRollback() {
    // ...
}
  1. Фиксируем результат теста в базе данных.
Kotlin
@Commit 
@Test
fun testProcessWithoutRollback() {
    // ...
}
  1. Фиксируем результат теста в базе данных.
@Rollback

Аннотация @Rollback указывает, нужно ли откатывать транзакцию для транзакционного тестового метода после завершения тестового метода. Если установлено в true, то транзакция откатывается. В противном случае транзакция фиксируется (см. также @Commit). Откат для интеграционных тестов в Spring TestContext Framework по умолчанию имеет значение true, даже если аннотация @Rollback не объявлена явно.

Если аннотация @Rollback объявляется как аннотация на уровне класса, то она определяет семантику отката по умолчанию для всех тестовых методов в иерархии тестового класса. Если аннотация @Rollback объявлена на уровне метода, она определяет семантику отката для конкретного метода тестирования, потенциально переопределяя семантику аннотации @Rollback или @Commit на уровне класса.

В следующем примере результат тестового метода не откатывается (то есть результат фиксируется в базе данных):

Java
@Rollback(false) 
@Test
void testProcessWithoutRollback() {
    // ...
}
  1. Не откатываем результат.
Kotlin
@Rollback(false) 
@Test
fun testProcessWithoutRollback() {
    // ...
}
  1. Не откатываем результат.
@BeforeTransaction

Аннотация @BeforeTransaction указывает, что аннотированный void метод следует выполнять до начала транзакции в случае тестовых методов, сконфигурированных на выполнение в рамках транзакции через аннотацию @Transactional из Spring. Методы, помеченные аннотацией @BeforeTransaction, не обязательно должны быть public, и они могут быть объявлены в методах интерфейса с реализацией по умолчанию на базе Java 8.

В следующем примере показано, как использовать аннотацию @BeforeTransaction:

Java
@BeforeTransaction 
void beforeTransaction() {
    // логика, которая должна выполняться до начала транзакции
}
  1. Выполняем этот метод перед транзакцией.
Kotlin
@BeforeTransaction 
fun beforeTransaction() {
     // логика, которая должна выполняться до начала транзакции
}
  1. Выполняем этот метод перед транзакцией.
@AfterTransaction

Аннотация @AfterTransaction указывает, что аннотированный void метод следует выполнять после завершения транзакции в случае тестовых методов, сконфигурированных на выполнение в рамках транзакции через аннотацию @Transactional из Spring. Методы, помеченные аннотацией @AfterTransaction, не обязательно должны быть public, и они могут быть объявлены в методах интерфейса с реализацией по умолчанию на базе Java 8.

Java
@AfterTransaction 
void afterTransaction() {
    // логика, которая будет выполняться после завершения транзакции
}
  1. Выполняем этот метод после транзакции.
Kotlin
@AfterTransaction 
fun afterTransaction() {
    // логика, которая будет выполняться после завершения транзакции
}
  1. Выполняем этот метод после транзакции.
@Sql

Аннотация @Sql используется для аннотирования тестового класса или тестового метода для конфигурирования SQL-скриптов, которые будут выполняться в отношении заданной базы данных во время интеграционных тестов. В следующем примере показано, как её использовать:

Java
@Test
@Sql({"/test-schema.sql", "/test-user-data.sql"}) 
void userTest() {
    // выполняем код, который использует тестовую схему и тестовые данные
}
  1. Выполняем два скрипта для этого теста.
Kotlin
@Test
@Sql("/test-schema.sql", "/test-user-data.sql") 
fun userTest() {
    // выполняем код, который использует тестовую схему и тестовые данные
}
  1. Выполняем два скрипта для этого теста.

Более подробную информацию см. в разделе "Декларативное выполнение SQL-скриптов с помощью аннотации @Sql".

@SqlConfig

Аннотация @SqlConfig определяет метаданные, которые используются для определения того, как анализировать и запускать SQL-скрипты, настроенные с помощью аннотации @Sql. В следующем примере показано, как её использовать:

Java
@Test
@Sql(
    scripts = "/test-user-data.sql",
    config = @SqlConfig(commentPrefix = "`", separator = "@@") 
)
void userTest() {
    // выполняем код, который использует тестовые данные
}
  1. Устанавливаем префикс комментария и разделитель в SQL-скриптах.
Kotlin
@Test
@Sql("/test-user-data.sql", config = SqlConfig(commentPrefix = "`", separator = "@@")) 
fun userTest() {
    // выполняем код, который использует тестовые данные
}
  1. Устанавливаем префикс комментария и разделитель в SQL-скриптах.
@SqlMergeMode

Аннотация @SqlMergeMode используется для аннотирования тестового класса или тестового метода, чтобы сконфигурировать объединение объявлений аннотации @Sql на уровне метода с объявлениями аннотации @Sql на уровне класса. Если аннотация @SqlMergeMode не была объявлена для тестового класса или тестового метода, то по умолчанию будет использоваться режим объединения OVERRIDE. В режиме OVERRIDE объявления аннотации @Sql на уровне метода будут эффективно переопределять объявления аннотации @Sql на уровне класса.

Обратите внимание, что объявление аннотации @SqlMergeMode на уровне метода переопределяет объявление на уровне класса.

В следующем примере показано, как использовать аннотацию @SqlMergeMode на уровне класса.

Java
@SpringJUnitConfig(TestConfig.class)
@Sql("/test-schema.sql")
@SqlMergeMode(MERGE) 
class UserTests {
    @Test
    @Sql("/user-test-data-001.sql")
    void standardUserProfile() {
        // выполняем код, который задействует тестовый набор данных 001
    }
}
  1. Устанавливаем режим объединения аннотаций @Sql в MERGE для всех тестовых методов в классе.
Kotlin
@SpringJUnitConfig(TestConfig::class)
@Sql("/test-schema.sql")
@SqlMergeMode(MERGE) 
class UserTests {
    @Test
    @Sql("/user-test-data-001.sql")
    fun standardUserProfile() {
        // выполняем код, который задействует тестовый набор данных 001
    }
}
  1. Устанавливаем режим объединения аннотаций @Sql в MERGE для всех тестовых методов в классе.

В следующем примере показано, как использовать аннотацию @SqlMergeMode на уровне метода.

Java
@SpringJUnitConfig(TestConfig.class)
@Sql("/test-schema.sql")
class UserTests {
    @Test
    @Sql("/user-test-data-001.sql")
    @SqlMergeMode(MERGE) 
    void standardUserProfile() {
        // выполняем код, который задействует тестовый набор данных 001
    }
}
  1. Устанавливаем режим объединения аннотаций @Sql в MERGE для конкретного тестового метода.
Kotlin
@SpringJUnitConfig(TestConfig::class)
@Sql("/test-schema.sql")
class UserTests {
    @Test
    @Sql("/user-test-data-001.sql")
    @SqlMergeMode(MERGE) 
    fun standardUserProfile() {
        // выполняем код, который задействует тестовый набор данных 001
    }
}
  1. Устанавливаем режим объединения аннотаций @Sql в MERGE для конкретного тестового метода.
@SqlGroup

@SqlGroup – это контейнерная аннотация, которая объединяет несколько аннотаций @Sql. Можно использовать аннотацию @SqlGroup для объявления нескольких вложенных аннотаций @Sql или использовать её в сочетании со средствами поддержки повторяющихся аннотаций из Java 8, где аннотацию @Sql можно объявлять несколько раз для одного класса или метода, неявно генерируя эту контейнерную аннотацию. В следующем примере показано, как объявить SQL-группу:

Java
@Test
@SqlGroup({ 
    @Sql(scripts = "/test-schema.sql", config = @SqlConfig(commentPrefix = "`")),
    @Sql("/test-user-data.sql")
})
void userTest() {
    // выполняем код, использующий тестовую схему и тестовые данные
}
  1. Объявляем группу SQL-скриптов.
Kotlin
@Test
@SqlGroup( 
    Sql("/test-schema.sql", config = SqlConfig(commentPrefix = "`")),
    Sql("/test-user-data.sql"))
fun userTest() {
    // выполняем код, использующий тестовую схему и тестовые данные
}
  1. Объявляем группу SQL-скриптов.