DevOps Zone is brought to you in partnership with:

Magnus has been working with Enterprise Integration professionally since 1999. He started off at the now infamous Boo.com, the Titanic of the dot-com era. Focus nowadays is: Enterprise Integration using IBM WebSphere Message Broker and/or Open Source light-weight integration frameworks like Apache Camel and Mule ESB. Groovy and Java development using agile methods and tools like Kanban or Scrum. DevOps tools and processes with focus on Continuous Delivery. Magnus has posted 1 posts at DZone. You can read more from them at their website. View Full User Profile

Lightweight Testing of Heavyweight IBM Message Broker Solutions

04.05.2013
| 3080 views |
  • submit to reddit

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.

Introduction

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.

Published at DZone with permission of its author, Magnus Palmér.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)