У меня есть система обмена сообщениями JMS с двумя очередями. Одна используется как стандартная очередь, вторая - очередь ошибок.
Эта система была реализована для обработки параллелизма в базе данных в моем приложении. В основном, есть пользователи, и у пользователей есть активы. Один пользователь может взаимодействовать с другим пользователем, и в результате этого взаимодействия его активы могут меняться. Один пользователь может взаимодействовать с одним пользователем одновременно, поэтому он не может начать другое взаимодействие до завершения первого. Однако один пользователь может взаимодействовать с другими пользователями несколько раз [до тех пор, пока они начали взаимодействие].
Что я сделал: создал «реестр взаимодействия» в Redis, где я храню ID пользователей, которые начинают взаимодействие. Во время взаимодействия я собираю все изменения, которые необходимо внести в активы второго пользователя, и после завершения взаимодействия я отправляю эти изменения в очередь [пользователь, который начал взаимодействие, сохраняется в исходной транзакции]. После завершения взаимодействия я очищаю идентификатор из реестра в redis.
Слушатель моей очереди получит сообщение с информацией об изменениях в пользователе, которые необходимо сделать. Слушатель получит все объекты, которые требуют изменения из базы данных, и обновит его. Слушатель будет проверять перед каждым обновлением, есть ли взаимодействие, запускаемое обновляемым пользователем. Если есть - слушатель откатит транзакцию и поместит сообщение обратно в очередь. Однако, если что-то не так, сообщение будет помещено в очередь ошибок и будет повторено несколько раз, прежде чем оно будет зарегистрировано и помечено как сбойное. Уф.
Теперь я нахожусь в точке, где мне нужно создать надлежащий интеграционный тест, чтобы убедиться, что никакие будущие изменения не испортят этого.
Позитивное тестирование легко, к сожалению, мне приходится тестировать сценарии, где во время обновлений есть исключение OptimisticLockFailureException, мое собственное UserInteractingException и некоторые другие исключения [catch (Exception e), то есть].
Я могу смоделировать свое исключение UserInteractingException, создав полезную нагрузку с сотнями объектов, которые будут обновлены слушателем, и изменив один из них в тесте. То же самое с OptimisticLockFailureException. Но я понятия не имею, как имитировать что-то еще [я даже не представляю, что это может быть].
Кроме того, этот сценарий тестирования, основанный на случайности [ну, вероятность того, что представленный сценарий не вызовет ошибку, очень мала] - это не то, что мне нравится. Я хотел бы иметь что-то более конкретное.
Есть ли другой, хороший, способ проверить этот сценарий?
Спасибо