Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Lightweight Testing of Heavyweight IBM Message Broker Solutions

DZone's Guide to

Lightweight Testing of Heavyweight IBM Message Broker Solutions

· DevOps Zone ·
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

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.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}