Утилита проверки интеграции Spring для конфликтующих конфигурационных контекстов

Question

Я работаю над приложением, в котором мы интенсивно используем интеграционные тесты, поскольку базовая структура, которую мы используем, работает в базе данных.

У меня есть классы тестов с использованием конфигурации контекста класса, такие как это:

@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguration(classes = ConfigA.class) 
public A_Test(){ 

} 

Большинство тестов используют тот же контекст, как и выше. У нас более 200 таких тестов. Но в последнее время мы нуждались некоторые дополнительные настройки для некоторых случаев применения, а также, как это:

@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguration(classes = {ConfigA.class, ConfigB.class}) 
public B_Test(){ 

} 

Проблема теперь, когда мы выполняем все тесты с Maven, или IDE бегунами, загруженного кэша для ConfigA больше не работает. Spring пытается воссоздать контекст для ConfigA, который терпит неудачу, потому что у нас уже настроена H2 DB, а Spring пытается создать схемы, таблицы которых не удается.

Чтобы преодолеть это, мы начали использовать @DirtiesContext для всех тестов. Результат превышает 1 час, что значительно снижает производительность разработчика.

Вопрос: возможно ли очистить контекст для тестов, таких как B_Test? @DirtiesContext (ClassMode = AFTER_CLASS) не помогает, потому что порядок тестов не гарантируется (и действительно мы не хотим идти этим путем). Он терпит неудачу, когда тестируются тесты типа B_Test. То же самое для @DirtiesContext (ClassMode = BEFORE_CLASS) наоборот

Можно ли имитировать @DirtiesContext (ClassMode = AFTER_CLASS) и @DirtiesContext (ClassMode = BEFORE_CLASS) в то же время на кучу тестов?

Или есть ли другой способ решить эту проблему в целом?

То, что мы пытались до сих пор:

1. JUnit Suites: не помогло ничего с контекстом весеннего
2. ContextHierarchies: не помочь делу, что B_Type тесты также пачкает контексте
3. Test Заказ: хорошо, что никто не очень рад реорганизации всех тестов, чтобы заставить его работать магически

Answer 1

Как насчет использования как @DirtiesContext (ClassMode = AFTER_CLASS), так и @DirtiesContext (Me thodMode = BEFORE_METHOD)?

Когда вы это сделаете, Spring перезагрузит контекст ConfigA.class и ConfigB.class непосредственно перед вызовом методов тестирования, аннотированных с помощью @DirtiesContext (MethodMode = BEFORE_METHOD). А потом, после завершения тестов B_Test, Spring отключит контексты (и следующий тестовый класс с SpringJUnit4ClassRunner загрузит его контекст).

Answer 2

Это по существу дубликат Make Spring Boot Recreate Test Databases.

Таким образом, вы, вероятно, должны убедиться, что используете уникальные имена для каждой встроенной базы данных, созданной с использованием вашего класса ConfigA.

Пожалуйста, прочитайте мои комментарии здесь для подробностей: https://stackoverflow.com/a/28867247/388980

Кроме того, смотрите комментарии в SPR-8849 для получения более подробной информации.

С уважением,

Сэм (автор Spring Framework TestContext)