我是IBM-MQ的新手，正在尝试了解如何对消息流执行单元测试。
我知道像CA Lisa这样的工具可以在系统测试级别进行服务虚拟化和测试。
但在我的案例中，我正在寻找像Java Junit测试这样的单元测试框架，开发人员可以在其中创建测试和所需的存根来独立测试IBM MQ消息流。
提前谢谢。
我们针对部署的流编写集成测试。我们使用Spring测试框架和Junit作为基础。
以下是关于我们测试的一些想法：
-
对于同步依赖项，我们要么编写模拟流，部署在单独的IIB应用程序中，要么使用JUnit助手处理SMTP和LDAP等事务。
-
对于异步依赖项(如IBM MQ)，我们在测试中使用JmsTemplate或直接使用JMS的IBM MQ类来发送和接收消息。在每次测试之前，我们用PCF消息清理队列。
-
对于文件节点，我们在真实流和Junit中使用环境变量
MQSI_FILENODES_ROOT_DIRECTORY来轻松查找文件。我们还将在每次测试开始清理之前清理File输入和输出目录。 -
为了加快单元测试的速度，并测试诸如断言没有消息到达之类的事情，我们在Junit测试中订阅了Monitoring Events。当我们接收到事务结束事件时，我们确信流已经完成，并且可以断言文件在那里，某个队列上没有消息，等等。
开始使用MQ消息传递REST API使用MQ V9.1.0.0中提供的消息传递REST API实际上是V9.0.0.4。
我过去使用过所有类型的解决方法，但如果您只想将消息放入队列并将它们从队列中取出，并安装了MQ 9.1或可以安装它，那么您可以使用MQ Messaging REST API
HTTP POST到/ibmmq/rest/v1/messageaging/qmgr/QMGR1/queue/Q1/message将把您的消息放到Q1
HTTP删除到/ibmmq/rest/v1/messageaging/qmgr/QMGR1/queue/Q1/message将从Q1 获取消息
我正在使用Postman来做这件事，但你没有理由不能使用SoapUI或任何其他你喜欢的测试工具。
目前需要注意的一点是，您仅限于文本消息，但考虑到XML、JSON或CSV的消息比例非常高，这很有可能符合您的要求。
在进入选择测试框架的阶段之前，我建议先选择一个好的测试策略。对于IIB消息流，我的建议是执行集成单元测试。此处
- "单元测试"是指使用存根而不是Test/QA/Prod API来处理消息流的依赖项，如队列、数据库、HTTP API、FTP API等。这是将整个消息流(而不是其中的一部分)视为一个单元。这也是为了隔离测试中的消息流，因为存根在测试期间是100%可控的
- "集成"是指多进程，即测试中的消息流在一个进程中，与消息流交互的存根在其他进程中。这与传统的Java JUnit测试不同，在传统的Java测试中，"模拟对象"通常与测试中的Java方法处于同一进程(JVM)中
进行集成单元测试的一个关键理由是反对传统的单元测试(针对消息流)。这是因为
- 如果可能的话，很难创建传统的单元测试，使测试中的消息流或测试中的部分消息流与存根处于同一进程(如JVM)中
- 从交付过程的角度来看，可能需要进行集成单元测试。许多团队都有消息流的集成设计文档。这些文档描述了消息流如何与其外部依赖项(队列、数据库等)交互，以及消息流内部的数据/消息转换。开发人员和项目经理通常倾向于针对设计文档进行测试，即测试与外部依赖项交互的消息流，以及数据/消息转换。传统的单元测试可能擅长测试数据/消息转换，但似乎不擅长测试外部依赖关系交互
- 为了避免重复的测试逻辑和工作，集成单元测试似乎是比传统单元测试更好的选择
要执行集成单元测试策略，可以使用各种类型的测试框架/工具。选择一个框架/工具的因素可能是开源与商业、高代码与中代码与无代码等
以下是一个用于进行集成单元测试的开源+无代码工具示例：https://apitestbase.io/docs/en/iib-integration-unit-testing.免责声明：我是工具开发人员。