Использование аннотации @Profile для приведения внешнего поведения

Question

Использование аннотации @Profile для приведения внешнего поведения

Существует несколько веб-весенних загрузочных java-приложений. Мне нужно подготовить несколько компонентов для тестирования интеграции. Моя задача - высмеять все внешние действия, такие как компоненты других проектов, вызовы db и т. Д. Я нашел решение для этого, используя @Profileаннотацию из Spring Framework. Вот пример . Я могу просто создать новый профиль и объявить две реализации бобов для каждого профиля: один для реального использования, для производства и еще один для тестирования интеграции, для stubbing. Это будет выглядеть так:

@Profile("PROD")
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
}

@Profile("MOCK")
@Configuration
@EnableWebSecurity
public class SecurityMockConfig extends WebSecurityConfigurerAdapter {
}

Но я сомневаюсь в этом дизайне. Это выглядит немного беспорядочно для меня. Является ли это решение приемлемым для заданий, которые у меня есть?

java,spring,spring-boot,integration-testing,stubbing,

0

Ответов: 1

Java, весна, весна-загрузка, интеграция тестирование, раскорчевка,

Похожие вопросы

score 0 · Accepted Answer

0

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

Мне это кажется очень странным. Не могли бы вы упаковать тесты своих модулей в приложении Spring Spring? Я так не думаю. Поэтому я хотел бы сказать, что это «плохой» дизайн, так как тестовые зависимости не должны быть встроены в производственный код.

Однако документация Spring о @Profileаннотации использует пример сегрегации среды.

Теперь есть вопрос, на который нужно ответить: что вы подразумеваете под «интеграционным тестированием»?

Это автоматический тест интеграции? Или вы хотите запустить приложение в разных режимах для групп тестирования?

Является ли это автоматическим интеграционным тестом, тогда нет оснований для использования @Profileаннотации, поскольку автоматические тесты и производственный код не будут упаковываться вместе.

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

Затем @Profileможно использовать для перехода от поддельного к производственному режиму, но только через файл конфигурации: поддельный профиль вызовет ваши поддельные внешние сервисы, тогда как производство вызовет реальные внешние сервисы.