testing - Grails 测试 JMS 消息传递

Question

我有一个使用两个队列实现的 JMS 消息传递系统。一个用作标准队列，第二个用作错误队列。

该系统的实现是为了处理我的应用程序中的数据库并发性。基本上，有用户，用户有 Assets 。一个用户可以与另一个用户交互，并且作为这种交互的结果，他们的 Assets 可以改变。一个用户可以一次与单个用户交互，因此他们不能在第一个交互完成之前开始另一个交互。但是，一个用户可以与其他用户进行多次交互 [只要他们开始交互]。

我所做的是:在 Redis 中创建一个“交互注册表”，我在其中存储开始交互的用户的 ID。在交互过程中，我收集了应该对第二个用户的 Assets 进行的所有更改，并在交互完成后将这些更改发送到队列 [开始交互的用户保存在原始事务中]。交互完成后，我从 redis 的注册表中清除 ID。

我的队列的监听器将收到一条消息，其中包含有关需要完成的用户更改的信息。监听器将从数据库中获取所有需要更改的对象并对其进行更新。 Listener 将在每次更新之前检查是否存在由正在更新的用户启动的交互。如果有 - 监听器将回滚事务并将消息放回队列中。但是，如果出现其他错误，消息将被放入错误队列，并在记录并标记为失败之前重试几次。呸。

现在我需要创建一个适当的集成测试，以确保 future 的更改不会搞砸它。

积极的测试很容易，不幸的是我必须测试场景，在更新期间有一个 OptimisticLockFailureException，我自己的 UserInteractingException 和其他一些异常 [catch (Exception e) that is]。

我可以通过创建一个包含数百个对象的负载来模拟我的 UserInteractingException，这些对象将由监听器更新并在测试中更改其中一个。与 OptimisticLockFailureException 相同。但我不知道如何模拟其他东西[我什至想不出它会是什么]。

此外，这种基于侥幸的测试场景 [好吧，所呈现的场景不会触发错误的可能性非常低] 不是我喜欢的东西。我想要更具体的东西。

还有其他好的方法可以测试这种情况吗？

谢谢

Answer 1

我按照我在原始问题中的描述做了，它似乎工作正常。我可以用 Camel 测试任何延迟。