CODEWITHSUNDEEP
ibm-mqmessagebrokeribm-integration-bus
Ven_QA
Ven_QA

Reputation: 31

Does anyone know how we can unit test IBM MQ Message Flows in an isolated way using stubs?

I am new to IBM-MQ and trying to understand how we can perform unit testing on message flows.

I am aware of the tools like CA Lisa to do Service Virtualization and testing at system testing level.

But in my case I am looking for the unit testing framework like Java Junit tests where developer can create tests and required stubs to test the IBM MQ Message flows independently.

Thank You in advance.

Upvotes: 2

Views: 7129

Answers (3)

Zheng Wang
Zheng Wang

Reputation: 111

Before going to the stage of choosing testing framework, I would suggest choosing a good testing strategy first. With IIB message flow, my suggestion is to do integration unit testing. Here

  • 'Unit testing' means using stubs instead of the Test/QA/Prod APIs for the message flow's dependencies like queues, databases, HTTP APIs, FTP APIs, etc. This is to treat an entire message flow (instead of one piece of it) as a unit. Also this is to isolate the message flow under test, because stubs are 100% controllable during testing.
  • 'Integration' means multi-process, i.e. the message flow under test is in a process, and the stubs that the message flow interacts with are in other processes. This is unlike the traditional Java JUnit tests where 'mock objects' are typically in the same process (JVM) as the Java method under test.

A critical justification for doing integration unit testing is to deprecate traditional unit testing (for message flows). This is because

  • It is difficult, if even possible, to create traditional unit test that makes the message flow under test, or parts of the message flow under test, to be in the same process (like JVM) as the stubs.
  • There could be requirement from delivery process perspective to do integration unit testing. Many teams have integration design documents for message flows. These documents describe how the message flows interact with their external dependencies (queues, databases, etc.), and the data/message transformations inside the message flows. Developers and project managers are often inclined to test against the design documents, that is, test the message flows interacting with external dependencies, as well as the data/message transformations. Traditional unit testing might be good at testing the data/message transformations, but seems not good at testing the external dependencies interactions.
  • To avoid duplicate testing logic and effort, integration unit testing seems a better choice than traditional unit testing.

To carry out integration unit testing strategy, there could be a variety of flavors of testing frameworks/tools that can be used. The factors for choosing one framework/tool could be open source vs commercial, high code vs medium code vs no code, etc.

Here is an example of open source + no code tool for doing integration unit testing: https://apitestbase.io/docs/en/iib-integration-unit-testing. Disclaimer: I am the tool developer.

Upvotes: 1

TJA
TJA

Reputation: 3051

Start using the MQ Messaging REST API Using the messaging REST API available in MQ V9.1.0.0 well actually V9.0.0.4 I believe.

I used to use all sort of workarounds in the past but if you want to just PUT messages on to queues and GET them off them and have MQ 9.1 installed or can install it then you can use the MQ Messaging REST API

An HTTP POST to .../ibmmq/rest/v1/messaging/qmgr/QMGR1/queue/Q1/message will PUT your message on to Q1

An HTTP DELETE to .../ibmmq/rest/v1/messaging/qmgr/QMGR1/queue/Q1/message will GET your message from Q1

I'm using Postman to do this but there is no reason you can't use SoapUI or any of your other favourite test tools.

One caveat at the moment is that you are limited to Text messages but given a very high percentage of messages are XML or JSON or CSV there's a fair chance this may fit the bill for you.

Upvotes: 1

Daniel Steinmann
Daniel Steinmann

Reputation: 2199

We write integration tests against deployed flows. We use the Spring Testframework and Junit as a base.

Here are some thoughts about our testing:

  • For synchronous dependencies we either write mock flows that we deploy in a separate IIB application, or we use JUnit helpers for things like SMTP and LDAP.

  • For asynchronous dependencies like IBM MQ we use in our tests the JmsTemplate or directly the IBM MQ classes for JMS to send and receive messages. Before each test we clean the queues with PCF messages.

  • For file nodes we use the environment variable MQSI_FILENODES_ROOT_DIRECTORY in the real flow and in Junit to easily find the files. We also clean the File input and output directories before each test to start clean.

  • To speed up the unit tests and to test things like assert that no message arrived we subscribe in our Junit tests to Monitoring Events. When we receive the Transaction End event we are sure the flow is finished and can assert that a file is there, that no message is on a certain queue, etc.

Upvotes: 1

Related Questions