базой? Таблицы могут использоваться разными тестами, соответственно могут возникать дедлоки. Может есть у кого опыт с этим, какие-то подход, паттерны, … в голове.. Спасибо
разве недостаточно выбрать правильный уровень изоляции?
Тут скорее про конфликт с данными в параллельных тестах
тут скорее не дэдлоки будут возникать, а ошибки тестов из-за несогласованности тестовых данных. как вариант, разделить тесты на те, которые только читают и те, что еще и пишут. чтение можно спокойно параллелить при условии, что общий тест-сет подготовлен корректный. сгруппировать тесты на запись данных, которые пишут одни и те же наборы сущностей. это по возможности. плюс явно надо начать аудит тестов. я понимаю, что "микросервисы" могут быть разной жирноты, но 1700 интеграционников - это уже перебор. возможно часть тестов можно перевести в юниты без подъема БД и прочих прелестей. если накат БД через liquibase идет долго, то можно сделать мердж чейнджсетов, чтобы их было поменьше, и прописать условие их выполнения. не уверен, что корректная практика, но имхо держать весь ворох изменений на протяжении всей жизни сервиса нафиг не надо.
Какая у вас база? Мы поднимаем в тестконтейнере инстанс постгри и в тестовой транзакции пишем тесты. Иногда приходится делать entitiyManager.flush() и .clean(), для инициализации, чтобы JPA'шные кеши не мешали. Все данные генерируются рандомно, поэтому у нас проблемы конфликтов не возникало. Но у нас и не 1700 интеграционных тестов :) Так что может быть не применимо.
Какая у вас база? Мы поднимаем в тестконтейнере инстанс постгри и в тестовой транзакции пишем тесты. Иногда приходится делать entitiyManager.flush() и .clean(), для инициализации, чтобы JPA'шные кеши не мешали. Все данные генерируются рандомно, поэтому у нас проблемы конфликтов не возникало. Но у нас и не 1700 интеграционных тестов :) Так что может быть не применимо.
Обсуждают сегодня