我有一个用两个队列实现的JMS消息传递系统。一个用作标准队列，第二个是错误队列。
该系统用于处理我的应用程序中的数据库并发。基本上，有用户和用户拥有资产。一个用户可以与另一个用户交互，并且由于这种交互，他们的资产可以改变。一个用户可以同时与单个用户交互，因此他们无法在第一个用户完成之前启动另一个交互。但是，一个用户可以多次与其他用户进行交互[只要他们开始交互]。
我所做的是：在redis中创建一个“交互式注册表”，我在其中存储开始交互的用户的ID。在交互期间，我收集应该对第二个用户的资产进行的所有更改，并在交互完成后将这些更改发送到队列[已启动交互的用户保存在原始事务中]。交互完成后，我在redis中清除注册表中的ID。
我的队列的监听器将收到一条消息，其中包含有关需要完成的用户更改的信息。监听器将获取需要从数据库进行更改的所有对象并进行更新。如果正在更新的用户启动了交互，则监听器将在每次更新之前进行检查。如果存在 - 侦听器将回滚事务并将消息放回队列中。但是，如果出现其他错误，则会将消息放入错误队列，并在记录并重新标记为失败之前重试几次。呼。
现在我正处于需要创建正确集成测试的位置，因此我确保未来的更改不会搞砸了。
正面测试很容易，不幸的是我必须测试场景，在更新期间有一个OptimisticLockFailureException，我自己的UserInteractingException＆amp;其他一些例外[catch（例外e）]。
我可以通过创建一个包含数百个对象的有效负载来模拟我的UserInteractingException，这些对象由监听器更新并在测试中更改其中一个。与OptimisticLockFailureException相同。但我不知道如何模拟其他东西[我甚至无法想到它会是什么]。
此外，这个基于侥幸的测试场景[好吧，呈现场景的机会不会触发错误非常低]不是我喜欢的。我想有更具体的东西。
还有其他好的方法来测试这种情况吗？
由于
答案 0 :(得分：0)
我按照我在原始问题中描述的那样做了，似乎工作正常。 我可以用骆驼来测试任何延迟。