Spring test - создайте первые bean-компоненты из тестовых классов и используйте реальный код

Question

Вопрос: как я могу убедиться, что бины из тестовых классов сначала создаются в Spring? Ситуация: у меня есть источник данных, который предоставляется во время выполнения и он получен через jndi. Во время компиляции я создаю один для БД в памяти и привязываю его к имени jndi. проблема в том, что сначала выполняется поиск jndi из реального кода.

Как я могу убедиться, что сначала создается тестовый DS, а затем выполняется поиск jndi из реального кода?

Редактировать после того как я нашел решение. Решение, которое я нашел:

Существует RepositoryConfig. java и RepositoryTestConfig. java. Прежде, чем я импортировал RepositoryConfig в RepositoryTestConfig.

Я изменил подход:

• Я сделал RepositoryTestConfig для расширения RepositoryConfig
• Я скрыл / переопределил bean-компонент DS в RepositoryTestConfig
• В EntityManager я добавил DS через Autowire

И проблема решена на 100%.

Для DS, выполненного через поиск jndi, я создал отдельный тест для докажите метод, поскольку реальный метод теперь скрывается / переопределяется формой DS RepositoryConfigTest.

Answer 1

Вы можете использовать @Profile

@Configuration
public class AppConfig {

    @Bean
    @Profile("test")
    public DataSource dataSourceTest() throws NamingException {
        return (DataSource) new JndiTemplate().lookup(env.getProperty("jdbc.test.url"));
    }

    @Bean
    @Profile("!test")
    public DataSource dataSource() throws NamingException {
        return (DataSource) new JndiTemplate().lookup(env.getProperty("jdbc.url"));
    }

}

и из класса теста установить активный профиль как «тест», например

@ExtendWith(SpringExtension.class)
@ActiveProfiles({ "test" })
@ContextConfiguration(classes = AppConfig.class) 
public class AppTest {

}

Пояснение

Создание @Bean связано с профилем в конфигурации. Когда «тестовый» профиль активен, будет создан экземпляр источника данных со свойством jdbc.test.url, а для любого другого профиля будет создан экземпляр источника данных со свойством jdbc.url.

Примечание. Вы можете выделить тестировать и расширять конфигурации bean-компонентов для разных классов. Общий код, чтобы помочь понять @Profile использование

Answer 2

В конце концов нашел ответ: по сути, есть 2 подхода:

1. использование @Profile и @ActiveProfile

2. Скрыть реальное / overide real DS через расширение класса конфигурации реального кода

1.

@Configuration
@EnableTransactionManagement
@EnableJpaRepositories(....)
@EntityScan(basePackages = "...")
public class RepositoryConfig {

    @Value("${ds-jndi-name}")
    private String dataSourceJndiname;


    @Bean("myDs")
    public DataSource dataSource() {
        JndiDataSourceLookup dataSourceLookup = new JndiDataSourceLookup();
        return dataSourceLookup.getDataSource(dataSourceJndiname);
    }

.....


}

2

@Configuration
public class RepositoryConfigTest extends RepositoryConfig{

    @Value("${ds-jndi-name}")
    private String dataSourceJndiname;

    @Primary
    @Bean("myDs")
    @SneakyThrows
    public DataSource dataSource() {
        EmbeddedDatabase datasource = new EmbeddedDatabaseBuilder()
                .setType(HSQL)
                .setSeparator(";")
                .addScript("classpath:/inmemorytablesdefinitions.sql")
                .build();
        bindDS(datasource);
        return datasource;
    }
 ......
 }

В репозитории, которые вы тест, который вы делаете:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = {RepositoryConfigTest.class})
public class AppRepositoryTest {

    private App givenApp;

    @Autowired
    private AppRepository appRepository;

    @Before
    public void setup() {
      ... whatever code
    }

 @Test
    public void shoudReadApp() {
        //given
         .....
        //when
           .......
        //then
        assert ...
    }
   }

Теперь в контексте времени тестовой компиляции у нас есть DS в памяти, во время выполнения мы имеем реальный DS, взятый через поиск jndi. В + нужно проверить и поиск jndi, поскольку DS времени выполнения скрыт.

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

Answer 3

вы должны настроить это с пользовательским @Configuration классом с @ComponentScan на вашем необходимом пакете