У меня есть приложение Spring Boot, написанное на Kotlin с RabbitMQ и PostgreSQL. Первичные ключи в базе данных имеют тип UUID и генерируются приложением с отдельной службой.
Для тестирования интеграции эта служба заглушается для генерации UUID последовательно, а не случайным образом, поскольку они проверяются по ожидаемому набору данных , В службе есть простой инкрементный счетчик.
Эта служба-заглушка имеет область действия Prototype, чтобы у каждого хранилища был свой собственный генератор UUID.
Этот подход работал идеально, пока мне не пришлось тестировать случаи с RabbitMQ. , Последовательность действий следующая:
- Выполнен запрос к контроллеру.
- Запись сохраняется в таблице истории операций.
- Сообщение отправляется в топ RabbitMQ. c.
- Затем сообщение возвращается в приложение.
- Новая запись сохраняется в таблице истории операций.
Когда этот тест выполняется один это проходит, и все работает, как ожидалось. Когда этот тест выполняется вместе с другими тестами, он не проходит. Ошибка возникает на шаге 5, когда он пытается сохранить новую запись в базе данных.
С помощью отладки я обнаружил следующее: В первом случае, когда тест запускается отдельно, экземпляр репозитория и служба генератора UUID Экземпляры одинаковы на этапах 2 и 5. Во втором случае, когда тест выполняется вместе с другим, экземпляр репозитория и экземпляр службы генератора UUID отличаются на этапах 2 и 5. В результате существуют разные счетчики, которые не синхронизирована. Это приводит к генерации того же идентификатора и исключения первичного ключа на шаге 5.
Как я понимаю, эта проблема возникает из-за того, что Spring RabbitMQ создает контейнеры слушателей, которые могут иметь свои собственные экземпляры bean-компонентов. Для меня до сих пор остается загадкой, как он выбирает создание нового экземпляра компонента или использование существующего.
Можете ли вы предложить какое-либо решение или другой подход для реализации этого теста?