Lightweight Testing of Heavyweight IBM Message Broker Solutions
This article shows a hands-on approach of how you can test your IBM WebSphere Message Broker solutions in a simple way using modern Groovy and Java tools.
The approach taken could actually be used with more or less any integration platform although some actually do have built-in ways of doing it, like Apache Camel.
Testing distributed enterprise integration using in our case IBM WebSphere MQ and IBM WebSphere Message Broker (IBM call it for their advanced ESB) is no so easily done as it ought to be.
The built in support for testing is not helping us much (see Test Client in resources).
At my current assignment there is a wealth of different approaches: JMeter, SoapUI, RFHUtil, MbTest, JUnit, end-to-end user testing, in-house developed testing tools.
I want a better approach that works well with our CI server and here is the start of that journey. To showcase I will use a vanilla IBM WebSphere Message Broker with default configuration (see appendix for links) and then one of the basic application samples for coordinated request/reply.
Imagine all you had to write was…
where: testFileName | expectedFileName | requestQ | replyQ | ignoreNamedElementsNames 'request1.xml' | 'reply1.xml' | 'GET_REQREP_IN' | 'GET_REQREP_OUT' | [ 'CompletionTime', ‘e2’] 'request2.xml' | 'reply2.xml' | 'GET_REQREP_IN' | 'GET_REQREP_OUT' | [ 'CompletionTime' ]
To “inject” the data into the test that will be run once per row above (omitting the details)
given: "A XML payload to send" and: "An expected reply XML payload" and: "Ignoring differences for configured element names" when: "The request is sent" then: "A reply is received" and: "The reply payload contains similar XML"
Since I don't seem to be able to properly format this article with regards to pictures etc., you will have to read the full story at my GitHub wiki instead.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)