@ piradian уже предоставил правильный ответ, я попытаюсь объяснить, почему он правильный.
@SpringBootTest
аннотация, когда помещается в тест в наиболее упрощенном виде (без параметров), пытается имитироватьпроцесс запуска микросервиса для теста как можно более точным.
В основном, для получения конфигурации необходимо выполнить два шага:
- Найти приложение для весенней загрузки
- Найти все конфигурации / компоненты, которые должны быть загружены
Для первого шага сначала пытается найти аннотацию @SpringBootConfiguration
.Это метааннотация, размещенная в аннотации @SpringBootApplication
.Это необходимо для поиска всех зарегистрированных компонентов / конфигураций.
Таким образом, он начинается с пакета, в котором находится тест (io.example.main
), и если он находит класс с @SpringBootConfiguration
в том же пакете (и да, он его находит) - тогда это означает, что этоБазовый пакет для поиска всех конфигураций / компонентов.Если он не находит такой класс, то он поднимается на один пакет вверх (io.example
) и начинает поиск снова, а затем, если не найден, идет (io
)
Когда класс найден,он начинает поиск конфигурации / компонентов вниз , начиная с пакета, в котором находится приложение.Именно так работает весеннее загрузочное приложение.И это является источником ошибки: пакет
io.example.main
не имеет никаких «подпакетов», поэтому тест с весенней загрузкой ничего не находит, и поэтому тест не пройден.
Если выпереместите SpringBootApplication на один пакет вверх, это решит проблему.потому что теперь первый шаг описанного выше процесса ищет в пакете io.example.main
, ничего не находит, ищет в io.example
, находит требуемый класс, и именно здесь начинается второй шаг.
Теперь,если вы используете @SpringBootTest
в сочетании с @ContextConfiguration
, это все равно что сказать весенней загрузке: «Не активируйте этот двухфазный поиск, просто возьмите классы конфигурации, которые я предоставляю, и начните с этого».Вот почему это работает для вас с @ContextConfiguration