Каков наилучший способ настройки нескольких методов TestExecutionListeners для TestSuite?

Question

Для оптимизации цели мне нужно настроить TestExecutionListeners вызывающую логику

В моем случае у меня есть один ApplicationContext и два типа тестов:

1. те, которые используют WebDriver (давайте назовем его ObservableTest)
2. те, которые использовать RestTemplate и JdbcTemplate (назовем его ApiTest)

Каждая из них использует тип свой собственный TestExecutionListener:

1. ObservableTest - ObservableTestListener
2. ApiTest - ApiTestListener

Оба ObservableTestListener и ApiTestListenerTestListener простираться где prepareTestInstance() определяется

ObservableTestListener реализует beforeTestClass() и afterTestClass() методы, а также ApiTestListener делает

мне нужно комбинировать типы тестов выше в одном JUnit TestSuite следующим способом:

1. Для каждого теста prepareTestInstance() вызывается
2. Как только первый ObservableTest собирается быть реализован, beforeTestClass() из ObservableTestListener является выполнен
3. То же самое с ApiTest
4. afterTestClass() из ObservableTestListener вызывается когда последний ObservableTest закончен в текущей Сюите
5. То же самое с ApiTest

Все стало еще более сложным, так как каждый тест может быть запущен в одном номере и в разной ApplicationContexts (из-за различные профили использования)

Буду очень благодарен за любую подсказку и рытье направление для реализации такой логики правильно

у меня есть две идеи до сих пор:

1. Реализация пользовательских Runner (я не уверен, что это даже возможно)
2. Notify TestContextManager как-то, что конкретный метод (beforeTestClass() или afterTestClass()) должен или не должен быть вызван. У меня есть ощущение, что @BootstrapWith обычай SpringClassRule должен помочь мне в этом

Спасибо!

Answer 1

API TestExecutionListener API в Spring TestContext Framework не имеет обратных вызовов жизненного цикла на уровне набора.

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

Я не предвижу, как это может пригодиться: SpringClassRule: вам все равно понадобится какой-то надежный механизм для определения, когда начинается и заканчивается тестовый набор. На самом деле это самая большая проблема, поскольку поддержка пакета в JUnit 4 осуществляется через определенный Runner. Итак, если вы запустите все свои тесты с помощью JUnit 4 Suite, вы можете создать собственные обратные вызовы жизненного цикла в пользовательском подклассе Suite.

С уважением,

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