Spring ApplicationContext не кэшируется для тестирования интеграции с Maven

Question

Когда интеграционные тесты начинаются с IDE ApllicationContext загружается только один раз, а затем делится между тестами и работает как аспект. Но выполнение mvn clean install новых ApllicationContext, созданных за каждый тест. По Spring doc Я настроил Maven-безотказный-плагин использовать единую вилку

<artifactId>maven-failsafe-plugin</artifactId> 
<version>2.12.4</version> 
<configuration> 
    <forkCount>1</forkCount> 
    <reuseForks>true</reuseForks> 
... 

Для кэширования ApplicationContext используется followin аннотации:

@ContextConfiguration(classes = TestConfig.class) 

Почему контекст не разделяется при создании приложения с Maven? На самом деле есть ли другие способы ускорить ИТ-тесты? Благодарю.

ОБНОВЛЕНО:

Это многомодульная проект Maven. Accordig Spring IT caching doc

Чтобы извлечь выгоду из механизма кэширования, все испытания должны выполняться в том же процессе или набора тестов. Этого можно достичь, выполнив все тесты в качестве группы в среде IDE. Аналогичным образом, при выполнении тестов с каркасом построения , таким как Ant, Maven или Gradle, важно сделать уверенным, что структура сборки не развивается между тестами. Для примера , если forkMode для плагина Maven Surefire установлен на всегда или pertest, инфраструктура TestContext не сможет кэшировать контексты приложений между тестовыми классами, и процесс сборки будет в результате значительно медленнее.

Так maven-failsafe-plugin 2.14 эта конфигурация равна forkMode = раз

Answer 1

Вы можете попробовать контекстное specifiyng место вместо классов:

@ContextConfiguration(locations = "classpath:test-context.xml") 

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

Это отсюда: http://static.springsource.org/spring/docs/current/spring-framework-reference/html/testing.html#testing-ctx-management

Также вы можете прочитать об ускорении модульных тестов здесь: http://www.nurkiewicz.com/2010/12/speeding-up-spring-integration-tests.html

UPDATE

Является ли ваш проект многопрофильным модуль Maven проекта? Соответственно к документации:

Значение по умолчанию forkCount = 1/reuseForks = верно, что означает, что Surefire создает один новый процесс JVM для выполнения всех тестов в одном модуле Maven.

Answer 2

Несколько вещей, которые вы можете захотеть взглянуть на:

версию

• из плагина и верных конфигурации параллельного выполнения. Согласно Surefire Fork Options - forkCount и reuseForks являются параметрами для Surefire версии 2.14 или новее. Фрагмент файла pom в состояниях OP версии 2.12.4
• , похоже, что-то в вашей конфигурации, которое все еще вызывает параллельное выполнение. В случае, когда запущено 20 потоков, я ожидаю, что 20 контекстов приложений будут созданы и кэшированы, так что все тесты, выполненные одним потоком, будут (повторно) использовать контекст приложения, созданный для него. Если это так, поведение ожидается в контексте нескольких потоков, выполняющих тесты - вопрос будет корректировать конфигурацию по количеству желаемых потоков
• может захотеть поэкспериментировать с различными версиями Surefire, поведение параллельного выполнения может отличаются. Я использовал Surefire 2.16 в других проектах и ​​без какой-либо пользовательской конфигурации, связанной с forking, все тесты выполняются однопоточными (как указано в конфигурации по умолчанию)

Я знаю, что это скорее список вещей, попробуйте, чем окончательный ответ на OP, но я отправил в надежде, что это может быть полезно