Automated testing of services using the MQ protocol using JMeter
Large distributed information systems often consist of smaller modules (subsystems) and are developed by teams of programmers using different platforms and approaches. Often, the exchange of data in such systems occurs in asynchronous mode and it is preferable to use message-oriented middleware (English Message-Oriented Middleware, MOM).
For unit and integration testing of such systems it is convenient to use the good old Apache JMeter.
For example, we select a small standard module of such a system. Suppose there is a certain adapter that reads an XML message from an incoming message queue, converts the structure of an XML message, and publishes the converted message to an outgoing message queue. As MOM, in this case, Websphere MQ 7.5 is used.
For manual testing of such a system, you can use the rfhutil utility that comes with Websphere MQ. However, if there are many options for transforming the structure of an XML document, then checking for such changes “by hand” is not justified. There is a big risk of not finding a mistake.
For the test plan, we need the following elements: User Defined Variables, Thread Group, JMS Publisher, JMS Subscriber. In order for JMeter to use JMS Publisher elements, JMS Subscriber needs to add jar libraries to the% jmeter_home% / lib / ext folder depending on which MOM you use.
In the case of Websphere MQ 7.5, the necessary jar libraries are located in the% wmq_home% / java / lib directory.
List of required libraries:
You need to create the% jmeter_home% / bindings folder and place the .bindings file generated using the JMSAdmin utility that comes with Websphere MQ.
The .bindings file contains all the necessary information to connect to the queue manager. In order to create a .bindings file for JMeter, you need to use the JMSAdmin utility that comes with Websphere MQ. % WebSphere_MQ_home% \ java \ bin> JMSAdmin.bat
Running WebSphere MQ classes for administering JMS
InitCtx> DEF CF (LOCAL.QCF) QMGR (TEST.QM) TRANSPORT (CLIENT) HOSTNAME (localhost) PORT (1415)
InitCtx> DEF Q QUEUE.IN) QMGR (TEST.QM) QUEUE (QUEUE.IN)
InitCtx> DEF Q (QUEUE.OUT) QMGR (TEST.QM) QUEUE (QUEUE.OUT)
InitCtx> end
Stop WebSphere MQ classes for JMS administration
Our test plan contains several basic elements: User Defined Variables, Thread Group, JMS Publisher, JMS Subscriber, View Results Tree.
The User Defined Variables element contains parameters for connecting to the MQ infrastructure.
The JMS Publisher element contains settings for working with the MQ queue (recording mode). There are several ways to specify which message should be written to the queue. In this example, for simplicity, the message is published directly in the script step.
The JMS Subscriber element contains settings for working with the MQ queue (read mode).
To verify that our test works as needed, we clear the message queues with which we will work. In the queue from which the test will read the messages, put the test message with the content “Hello, Habrahabr!”
Now run our script.
We see that the test message was successfully queued QUEUE.IN.
Also, the message from the QUEUE.OUT queue was successfully read.
The main idea of the article is to show how JMeter can work with the MQ protocol. Otherwise, test scripts can be modified (working with Assertes, variables, reading from a file, etc.) in the same way as during functional testing of services working on other protocols (for example, HTTP).
For unit and integration testing of such systems it is convenient to use the good old Apache JMeter.
For example, we select a small standard module of such a system. Suppose there is a certain adapter that reads an XML message from an incoming message queue, converts the structure of an XML message, and publishes the converted message to an outgoing message queue. As MOM, in this case, Websphere MQ 7.5 is used.
JMerter setup
For manual testing of such a system, you can use the rfhutil utility that comes with Websphere MQ. However, if there are many options for transforming the structure of an XML document, then checking for such changes “by hand” is not justified. There is a big risk of not finding a mistake.
For the test plan, we need the following elements: User Defined Variables, Thread Group, JMS Publisher, JMS Subscriber. In order for JMeter to use JMS Publisher elements, JMS Subscriber needs to add jar libraries to the% jmeter_home% / lib / ext folder depending on which MOM you use.
In the case of Websphere MQ 7.5, the necessary jar libraries are located in the% wmq_home% / java / lib directory.
List of required libraries:
- com.ibm.mq.commonservices.jar
- com.ibm.mq.headers.jar
- com.ibm.mq.jar
- com.ibm.mq.jmqi.jar
- com.ibm.mq.pcf.jar
- com.ibm.mqjms.jar
- connector.jar
- dhbcore.jar
- fscontext.jar
- jms.jar
- jta.jar
- mqcontext.jar
- providerutil.jar
You need to create the% jmeter_home% / bindings folder and place the .bindings file generated using the JMSAdmin utility that comes with Websphere MQ.
Creating a .bindings file
The .bindings file contains all the necessary information to connect to the queue manager. In order to create a .bindings file for JMeter, you need to use the JMSAdmin utility that comes with Websphere MQ. % WebSphere_MQ_home% \ java \ bin> JMSAdmin.bat
Running WebSphere MQ classes for administering JMS
InitCtx> DEF CF (LOCAL.QCF) QMGR (TEST.QM) TRANSPORT (CLIENT) HOSTNAME (localhost) PORT (1415)
InitCtx> DEF Q QUEUE.IN) QMGR (TEST.QM) QUEUE (QUEUE.IN)
InitCtx> DEF Q (QUEUE.OUT) QMGR (TEST.QM) QUEUE (QUEUE.OUT)
InitCtx> end
Stop WebSphere MQ classes for JMS administration
Create a test plan
Our test plan contains several basic elements: User Defined Variables, Thread Group, JMS Publisher, JMS Subscriber, View Results Tree.
The User Defined Variables element contains parameters for connecting to the MQ infrastructure.
The JMS Publisher element contains settings for working with the MQ queue (recording mode). There are several ways to specify which message should be written to the queue. In this example, for simplicity, the message is published directly in the script step.
The JMS Subscriber element contains settings for working with the MQ queue (read mode).
Run test and view results
To verify that our test works as needed, we clear the message queues with which we will work. In the queue from which the test will read the messages, put the test message with the content “Hello, Habrahabr!”
Now run our script.
We see that the test message was successfully queued QUEUE.IN.
Also, the message from the QUEUE.OUT queue was successfully read.
Conclusion
The main idea of the article is to show how JMeter can work with the MQ protocol. Otherwise, test scripts can be modified (working with Assertes, variables, reading from a file, etc.) in the same way as during functional testing of services working on other protocols (for example, HTTP).