Singleton config for tests

[karle0wne]

разве не прекрасно?
было

стало

[karle0wne]

еще пруф про использование аннотации @Transactional для использования интеграционных тестов с сингтоном

без него (разъебывает из за грязных данных)

с ним 👌

[karle0wne]

ролбек после теста

[karle0wne]

на самом деле подобная фишка уже в магисте использовалась. были тесты на DslQuery с аннотацией @Sql - на них висела @Transactional чтоб миграция откатывалась после теста

[ex01tus]

Выигрыш в 2+ раза по скорости – лайк. Интересное использование @Transactional, не сталкивался раньше с таким.

[ex01tus]

На этом месте становится совсем тяжко. Абстрактный кафка-конфиг, который наследуется от абстрактного дб-конфига и который является родителем для абстратного кафка-и-дао-конфига, который порождает, собственно, тест.

Для меня шансы разобраться как работает (или почему не работает) тест в такой ситуации околонулевые. Я бы подумал над тем, как уйти от наследования в тестах совсем. Кажется, что оно сильно усложняет тестовые классы и лишает их одной из основных функций – простого и понятного документирования кода.

Можно посмотреть в сторону явного подключения конфиг-бинов в тестовый класс или что-то такое.

[D-Baykov]

Можно в целом отказаться от абстрактных классов и наследования и в сетапе теста создавать нужные инстансы для теста. Например, если надо поднять PG и kafka, то

private PostgresTestEnviroment postgresTestEnviroment;
private KafkaTestEnviroment kafkaTestEnviroment;

@Before
public void setup() {
    postgresTestEnviroment = new PostgresTestEnviroment();
    kafkaTestEnviroment = new KafkaTestEnviroment();
}

и далее работать уже с этими инстансами (если надо)

[inallyoung]

лично мне кажется лучше пожертвовать скоростью ради чистоты прохождения тестов.

[ggmaleva]

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

Мб стоит вынести в отдельный стартер тестовые конфиги под различные кейсы - бд, кафка и тд.
И подключать как вариант через анноташки.

Я вроде видел задачку в бэклоге на выработку подхода и унифицирование тестов. Это как раз выглядит как ее реализация.

[echerniak]

Поресёрчил в контексте переиспользования контейнеров непосредственно в рамках функционала testcontainers - там разработчики by design сделали так, чтобы подобная фича могла нормально работать только на локальной машине (требуется создавать конфигурацию в home-директории, что заставляет создавать файлы на всех серверах, где будут гонятся подобные тесты). Основная причина - в таком режиме контейнеры могут не вырубиться и продолжить "висеть" после прохождения всех тестов.

[karle0wne]

Поресёрчил в контексте переиспользования контейнеров непосредственно в рамках функционала testcontainers - там разработчики by design сделали так, чтобы подобная фича могла нормально работать только на локальной машине (требуется создавать конфигурацию в home-директории, что заставляет создавать файлы на всех серверах, где будут гонятся подобные тесты). Основная причина - в таком режиме контейнеры могут не вырубиться и продолжить "висеть" после прохождения всех тестов.

круто, конечно, хоть я не все уловил, на самом деле, что там имелось ввиду.

это может быть использовано в кейсах, когда мы создаем в рамках конфига контейнер, например, через @Container или @ClassRule, в таких кейсах контейнер заново переподнимается каждый раз, а с опцией .withReuse(true) видимо он не дает конейнеру закрыться. и при этом эта фича еще имеет некоторые ограничения , подходит только для использования на локальной машине 🤔

возможно это лучше, чем static{} , но я уже не готов еще раз перелопачивать 😅

если по теме, то контейнеры реализуют интерфейс AutoCloseable поэтому в такой конфигурации как описаны здесь, через static{}, проблем с подвисшими контейнерами быть не должно (не больше чем с обычным конфигом)

[karle0wne]

лично мне кажется лучше пожертвовать скоростью ради чистоты прохождения тестов.

чистота поддерживается аннотацией Transactional

[karle0wne]

немного переосмыслил в #308 архитектуру