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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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