powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Map
Форумы / Java [игнор отключен] [закрыт для гостей] / JUnit5 inheritance
8 сообщений из 8, страница 1 из 1
JUnit5 inheritance
    #40098201
Фотография -=Koba=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Подскажите, почему не и инициализируется MockBean в ChildTest

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
@SpringBootTest
@ActiveProfiles("dev")
@MockBeans({@MockBean(TestProvider.class)})
public class ParentTest {
    @BeforeAll
    public static void setSystemProperty() {
        Properties properties = System.getProperties();
        properties.setProperty("spring.profiles.active", "dev");
    }
}

public class ChildTest extends ParentTest{
@Autowired
private TestProvider testProvider - NULL
}



На Junit4 делал подобное, работало
...
Рейтинг: 0 / 0
JUnit5 inheritance
    #40098208
Такое делать не надо ни в JUnit4, ни в JUnit5. При решении любых задач наследование нужно рассматривать в последнюю очередь. Проблема которую ты хочешь решить - это переиспользование настроек спринга (аннотации над классом), верно? Это делается созданием своей композитной аннотации. Что-то такое:

Код: java
1.
2.
3.
@Retention(RetentionPolicy.RUNTIME)
@ContextConfiguration({"classpath:/dao-context.xml", "classpath:/service-context.xml"})
public @interface ComponentTest { }

А затем уже на целевом тестовом классе ставим эту новосозданную аннотацию:
Код: java
1.
2.
3.
@RunWith(SpringJUnit4ClassRunner.class) 
@ComponentTest
public class BlahTest {}

Это пример для JUnit4 ( @RunWith(SpringJUnit4ClassRunner.class) ). А вот статья о том же в JUnit5.
...
Рейтинг: 0 / 0
JUnit5 inheritance
    #40098209
Фотография -=Koba=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,

У меня задача больше, чтоб приложение поднималось один раз, а все тесты работали в одном контексте
...
Рейтинг: 0 / 0
JUnit5 inheritance
    #40098210
Дак наследование тут не причем. Spring тесты всегда так и работают - контекст поднимается один раз, а тестов с этим контекстом - сколько хочешь. Для этого ничего особенного делать не надо.

Контексты будут подниматься 2ой раз только если:
- У них разные настройки (properties, profiles, возможно даже MockBeans)
- На тестах стоит @DirtiesContext
- Тесты находятся в разных Maven модулях
...
Рейтинг: 0 / 0
JUnit5 inheritance
    #40098213
Фотография -=Koba=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,

Угу спасибо, тогда наверное, что-то у себя напортачил
...
Рейтинг: 0 / 0
JUnit5 inheritance
    #40098226
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну наследование не наследование тут все таки не логика как таковая а вопрос инициализации и главное чтобы проблема была решена.
Ну это такая рекомендация чтобы расшарить единный контекст среди всех тестов использвать парент класс. Почти всегда такой же подход использую в интеграционных тестах.
Вроде как спринг контекст привязан к самому классу над которым стоит SpringBootTest вот только чтобы spring не пробовал его инстациировать он должен быть abstract и в имя тоже нужно Abstract prefix добавить точно уже не помню обязательно ли.
...
Рейтинг: 0 / 0
JUnit5 inheritance
    #40098292
lleming
Ну наследование не наследование тут все таки не логика как таковая а вопрос инициализации и главное чтобы проблема была решена.
Ну если так подходить к написанию кода, то плохой код который решает проблему - это так же хорошо, как и хороший код который решает проблему.
lleming
Ну это такая рекомендация чтобы расшарить единный контекст среди всех тестов использвать парент класс. Почти всегда такой же подход использую в интеграционных тестах.
Это не рекомендация - это просто первое что приходит в голову. Поэтому в очень многих проектах сделано именно так. Но если чуть подумать/поисследовать, то находится подход намного более удобный - собсно композитные аннотации.
llemingВроде как спринг контекст привязан к самому классу над которым стоит SpringBootTestЭто не так, тестовый спринг контекст привязан к уникальным конфигурациям среди всех тестовых классов. Т.е. если у нас есть 100 тестовых классов с одной конфигурацией и 100 с другой, то всего будет создано 2 спринговых контекста.
llemingвот только чтобы spring не пробовал его инстациировать он должен быть abstract и в имя тоже нужно Abstract prefix добавить точно уже не помню обязательно ли.И это не так. Инициализирует тесты JUnit. Абстрактные классы конечно не могут быть проинициализированы, за сим JUnit не будет их трогать. Ну соответственно он не будет инициализировать и спринговый контекст.
...
Рейтинг: 0 / 0
JUnit5 inheritance
    #40098753
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev
Такое делать не надо ни в JUnit4, ни в JUnit5. При решении любых задач наследование нужно рассматривать в последнюю очередь. Проблема которую ты хочешь решить - это переиспользование настроек спринга (аннотации над классом), верно? Это делается созданием своей композитной аннотации. Что-то такое:

Код: java
1.
2.
3.
@Retention(RetentionPolicy.RUNTIME)
@ContextConfiguration({"classpath:/dao-context.xml", "classpath:/service-context.xml"})
public @interface ComponentTest { }

А затем уже на целевом тестовом классе ставим эту новосозданную аннотацию:
Код: java
1.
2.
3.
@RunWith(SpringJUnit4ClassRunner.class) 
@ComponentTest
public class BlahTest {}

Это пример для JUnit4 ( @RunWith(SpringJUnit4ClassRunner.class) ). А вот статья о том же в JUnit5.


Мне вот не очевидно в данном случае что @ContextCongiguration создаст именно один контект и не будет создаваться новый для каждого теста. Тут по сути junit test должен увидеть аннотацию springbootrunner узнать что это junit extension передать управление/вызвать процедуру extensionа с именем теста(класса) который уже еще раз springbootrunner просканит и увидит contextconfiguration и тут он должен понять что нужно воспользовалься закэшированным контекстом. Что в данном случае будет ключем ?

Но еще мне наверное следует подчеркнуть что особой выгоды не увидел через абстрактный класс и наследование делать единный контект для простых тестов. Выгода в производительноти не то чтобы значительна (в рамках пары сотен тестов). А вот в интеграционных тестах когда в тестконтейнере запускаются третьи сервисы вот тут и вопрос как расшарить поднятый сервис и связать его жизненый цикл с контекстом спринга и тестами в которых этот сервис использоваться будет.

StanislavЭто не рекомендация - это просто первое что приходит в голову. Поэтому в очень многих проектах сделано именно так. Но если чуть подумать/поисследовать, то находится подход намного более удобный - собсно композитные аннотации.

это не то что первое пришло в голову. Первое что пришло в голову что нужно поднятый третий сервис как то расшарить в единый контекст. Остальное детали реализации. Если прям исследовать нужно лезть в описание junit как как его extensions реализованы и как springboot extension вызывается инициализируется и привязывается в junit тесту. Но там отдельная песня за час не разобраться а времени как всегда в недостатке.
...
Рейтинг: 0 / 0
8 сообщений из 8, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / JUnit5 inheritance
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]