Вопрос или проблема
У меня есть перехватчик конечной точки, который предназначен для черного списка всех, кроме нескольких пользователей, от использования некоторых устаревших конечных точек, но наш набор интеграционных тестов все еще сильно зависит от этих старых конечных точек.
Я заставляю Spring внедрять фиктивного тестового кандидата для перехватчика в интеграционных тестах, чтобы они могли выполняться, но мне все равно нужно запустить тесты на самом производственном перехватчике.
Есть ли легкий способ поменять, какой кандидат автозаполнения используется для зависимости сервиса, только для одного класса интеграционного теста?
Моя текущая лучшая идея – иметь третьего кандидата, своего рода селектора зависимостей, которому указано выбрать производственную реализацию для одного класса теста, но это грязное решение. Буду признателен за любые идеи 🙂
Ответ или решение
Вопрос о переключении между кандидатами бинов в Spring в рамках одного теста является довольно распространенной задачей, особенно когда дело касается интеграционного тестирования, где требуется тестировать как старые, так и новые эндпоинты. Давайте рассмотрим несколько решений для вашего случая, который включает в себя создание интерсептора с возможностью черного списка пользователей для потенциально устаревших энэдпоинтов.
Подход 1: Использование профилей Spring
Одним из наиболее простых и чистых способов для управления зависимостями является использование профилей Spring. Вы можете создать отдельный профиль для интеграционных тестов, который будет использовать вашу тестовую реализацию бина, а затем в том же тесте включить профиль для использования продакшн-версии.
@ActiveProfiles("test") // Или имя вашего тестового профиля
@SpringBootTest
public class MyIntegrationTests {
@Autowired
private MyInterceptor myInterceptor; // Будет инжектирован тестовый экземпляр
@Test
public void testWithProductionInterceptor() {
// Тут можете включить продакшн-версию
context.getEnvironment().setActiveProfiles("prod");
// Запустите ваш тест
}
}Подход 2: Использование @MockBean и @TestConfiguration
Еще один вариант — это использование аннотации @MockBean, чтобы замокать зависимости в Integration Test, и продиктовать Spring использовать исходный интерсептор только в этом тесте:
@SpringBootTest
public class MyIntegrationTests {
@MockBean
private MyInterceptor myInterceptor; // Mockito будет создать заглушку вместо реального бина
@Test
public void testWithProductionInterceptor() {
// Создайте отдельный контекст, если необходимо
// И настройте реальный Interceptor как нужно
// ...
}
}Подход 3: Замена бина в @TestConfiguration
Вы можете создать класс конфигурации для тестирования, который заменит бины только для всех тестов в этом классе. Например:
@TestConfiguration
public class TestInterceptorConfiguration {
@Bean
public MyInterceptor myInterceptor() {
return new ProductionInterceptor(); // Ваша продакшн версия
}
}
@SpringBootTest(classes = TestInterceptorConfiguration.class)
public class MyIntegrationTests {
@Autowired
private MyInterceptor myInterceptor; // Будет инжектирован продакшн экземпляр
@Test
public void runIntegrationTest() {
// Ваш тест здесь
}
}Заключение
Каждый из предлагаемых методов имеет свои преимущества и недостатки, но все они позволяют эффективно управлять заменой бинов в Spring. Выбор подхода зависит от специфики вашего проекта и стиля написания тестов. Профили позволяют гибко управлять окружением, в то время как @MockBean и @TestConfiguration достаточно удобны для изоляции изменений только в рамках одного теста.
В конечном счете, приложение Spring способно предложить множество инструментов для решения такой задачи, что заметно упрощает процесс тестирования различных компонентов вашего приложения.