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

@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 {
    // cтіло класу...
}
  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. "Забруднений" контекст після поточного тестового методу.

Якщо nи використовуєш анотацію @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() {
    // виконуємо код, який використовує тестову схему та тестові даніa
}
  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

@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-скриптів.