Центральный SpringBootTest, который запускается в ApplicationContext каждого модуля maven отдельно

Что-то не так в этой настройке, позвольте мне объяснить:

Итак, вы говорите, что у вас есть «основной» модуль с собственным тестом @SpringBootTest, что означает, что это приложение для загрузки Spring.

С другой стороны, вы говорите, что у вас есть модули A и B, которые сами по себе являются весенними загрузочными приложениями. Но если это так, они не могут зависеть от другого приложения весенней загрузки (ядра), я имею в виду, что модуль приложения весенней загрузки не может зависеть от другого модуля приложения весенней загрузки, это не имеет смысла и не работает в maven.

Еще один концерт, который приходит мне на ум: в любом приложении с весенней загрузкой мы обычно используем «плагины», такие как: система измерения, система регистрации, привод и так далее. Обычно для этой цели есть стартеры, мы определяем их в maven, и загрузочное приложение Spring загружает их автоматически. Однако мы относимся к ним как к «сторонним» в нашем приложении и никогда не запускаем «их» тесты при компиляции нашего приложения. То, что вы описали, противоречит этому подходу.

Итак, в моем понимании (и опять же, я могу ошибаться), вы должны:

1. Создайте стартер (модуль автоконфигурации) из вашего «основного» модуля. Это не будет весеннее загрузочное приложение само по себе, и на нем не будет @SpringBootTest. Только простые модульные/интеграционные тесты (возможно, управляемые Spring, но не Spring boot в смысле того, что делает @SpringBootTest). У вас также не будет spring-boot-maven-plugin в pom этого модуля, а также не будет метода main ни в одном классе (вообще никакого @SpringBootApplication).

2. В модулях А и Б - подключите этот модуль автоконфигурации, он загрузится автоматически и обеспечит требуемый функционал. Тесты модуля A должны тестировать код/потоки модуля A и не должны проверять функциональность «основного» модуля, это для «основных» тестов, чтобы проверить функциональность «основного» модуля.

3. В модулях A и B, когда у вас есть @SpringBootTest, будет загружен основной модуль, и часть вашего кода может сломаться, потому что он не «соответствует ожиданиям» основного модуля (например, вы не разместили правильную аннотацию или что-то в этом роде) - в этом случае тест не пройдёт и вам придётся исправлять код модуля А, например.

Обновление 1 После прочтения комментариев:

Я думаю, что это возможно, и решение должно включать следующие шаги:

1. Из ядра модуля, содержащего тест AdminControllerIntegrationTest, создайте дополнительный тестовый артефакт jar. эта ссылка содержит технические инструкции того, что должно быть размещено в pom.xml ядре модуля.

2. Модули вашего приложения весенней загрузки должны зависеть от этого тестового артефакта в тесте области, примерно так:

<dependency>
  <groupId>com.foo</groupId>
  <artifactId>core</artifactId>
  <version>1.0</version>
  <type>test-jar</type>
  <scope>test</scope>
</dependency>

3. С этого момента это становится сложным, потому что это действительно зависит от того, что именно происходит в тесте и как Spring все подключает. В «самой простой» ситуации для этого шага вам нужно будет убедиться, что ваш плагин surefire/failsafe имеет версию 2.15+. : в этой версии добавлена ​​поддержка параметра dependenciesToScan, который будет содержать ядро ​​модуля, так что во время сборки вашего весеннего загрузочного приложения плагин также будет запускать AdminControllerIntegrationTest. По крайней мере, это будет в пути к классам тестов... Оттуда вам может потребоваться выполнить некоторые настройки на уровне весны, не видя кода, трудно сказать, что происходит. См. эту тему для получения дополнительной информации.