【问题标题】:Grails test JMS messagingGrails 测试 JMS 消息传递
【发布时间】:2012-01-05 17:41:38
【问题描述】:

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

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

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

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

现在我需要创建一个适当的集成测试,以确保将来不会发生任何更改。

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

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

此外,这种基于侥幸的测试场景 [嗯,呈现的场景不会触发错误的机会非常低] 不是我喜欢的。我想要一些更具体的东西。

还有其他好的方法来测试这种情况吗?

谢谢

【问题讨论】:

    标签: testing grails jms integration-testing message-queue


    【解决方案1】:

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

    【讨论】:

      猜你喜欢
      • 2011-02-26
      • 2011-01-29
      • 2016-02-23
      • 1970-01-01
      • 2019-07-18
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-02-02
      相关资源
      最近更新 更多