Как определить spring.config.location в тестах Spring Boot и JUnit?

Question

Как мы можем программно настроить Spring Boot для определения новых значений свойств spring.config.name и spring.config.location при выполнении тестов JUnit?

Например, если мы хотим определить эти свойства при запуске самого приложения, мы можем использовать что-то вроде (в Kotlin):

fun main(args: Array<String>) {
//  SpringApplication.run(Application::class.java, *args)

    val applicationContext = SpringApplicationBuilder(Application::class.java)
        .properties(
            """spring.config.name:
                ${getSpringConfigNames()}
            """,
            """spring.config.location:
                ${getSpringConfigLocationPaths()}
            """
        )
        .build()
        .run(*args)

//  val environment = applicationContext.getEnvironment()
}

Но я не смог найти способ настроить это для использования в тестах JUnit.

Редактировать

Здесь есть осложнение из-за ограничения пружинного башмака.

Я хотел бы использовать целую папку и ее подпапки в качестве допустимых расположений для поиска файлов конфигурации (например, у нас могут быть папки для определенных сред, баз данных, сторонних производителей и т. Д.).

При запуске приложения было возможно создать метод, в данном случае getSpringConfigLocationPaths(). И этот метод создает разделенный запятыми список со всеми папками внутри «основной» папки.

Например, для основной папки src/main/resources/configuration будет выведено:

src/main/resources/configuration,
src/main/resources/configuration/environments,
src/main/resources/configuration/environments/development,
src/main/resources/configuration/environments/staging,
src/main/resources/configuration/environments/testing,
src/main/resources/configuration/environments/production,
src/main/resources/configuration/environments/common

Как мы можем решить эту ситуацию при использовании тестов JUnit и Spring Boot?

К сожалению Spring Boot не позволяет что-то вроде src/main/resources/configuration/**/*.

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

Answer 1

Тесты, которые запускают пружинную загрузку, должны быть тщательно разработаны Существует целая среда тестирования для весенних загрузочных тестов, поэтому, очевидно, рассмотрите возможность использования этой среды.

Когда дело доходит до управления конфигурацией, я предлагаю рассмотреть следующее:

Существует два типа тестов:

• Тесты, которые загружают конкретную конкретную конфигурацию (набор компонентов), например, если вы хотите проверить только DAO, вы загружаете конфигурацию для этого dao. В этом случае конфигурация должна быть «адаптирована» к потребностям конкретного теста, и «полная» конфигурация не требуется.

Например, если микросервис содержит конфигурацию для базы данных (пользователя, пароля, схемы и т. Д.) И, например, для управления сообщениями, нет необходимости указывать конфигурацию системы обмена сообщениями при тестировании DAO, обмена сообщениями бобы все равно не будут загружены.

Обычно тест этого «типа» будет выглядеть так:

@SpringBootTest(classes = {RelationalDbDaoConfiguration.class}) 
public class MyDaoTest {

}

Если у вас нет конфигурации для ваших нужд, вы можете использовать @MockBean, чтобы смоделировать ненужные компоненты или даже создать пользовательскую конфигурацию в src/test/java, чтобы она была только в тестовом пути к классам. Имеет смысл использовать @TestConfiguration, но это выходит за рамки вопроса.

Теперь, чтобы загрузить конфигурацию только для БД, существует множество опций, если назвать несколько:

• @ ActiveProfiles ("dao") на тестовом классе + добавление "application-dao.properties/yaml" в src/test/resources или src/test/resources/config

• Использование @TestPropertySource(locations = "classpath:whatever.properties") при тестировании

• Создайте специальный компонент "DbProperties" и инициализируйте его программно весной, это может иметь смысл, если вы знаете некоторые подробности о контексте, в котором тест выполняется только во время фактического выполнения теста (например, если вы запускаете база данных перед тестом, и порт создается динамически, но это действительно довольно сложная настройка и выходит за рамки этого вопроса) + компонент источника данных может прочитать эти свойства

• Используйте атрибут @SpringBootTest 'properties, чтобы предоставить определения «мелкозернистых» свойств

• Вроде бы очевидно, но я все равно упомяну об этом: поместите application.properties в src/test/resources, он переопределит обычные конфигурации

Второй тип тестов - это когда вы загружаете "весь" микросервис, обычно это тесты, которые не имеют параметра "классы" в @SpringBootTest аннотации

@SpringBootTest // note, no actual configurations specified
public class MyMicroserviceTest {
  ...
}

Теперь, это определенно требует указания целого набора конфигураций, хотя методы для фактического указания этих конфигураций по-прежнему применимы (только содержимое файлов конфигурации будет другим).

Я не предлагаю использовать spring.config.location во время теста, потому что это означает, что тест зависит от некоторого внешнего ресурса, что делает всю настройку еще более сложной.

Answer 2

Если это конфигурация на основе XML,

@ContextConfiguration(locations = "/app-context.xml")

Если это аннотация, управляемая классами конфигурации,

@ContextConfiguration(classes = {AppCOnfig::class, AnotherCOnfig::class}

Они будут определены на уровне класса в классе модульного теста, который вы запускаете.

Далее, если у вас есть профили для Junit, @ActiveProfiles("myProfile") будет добавлено в тестовый класс.