-
Notifications
You must be signed in to change notification settings - Fork 6
Article about testing WMB
This article shows a hands-on approach of how you can test your IBM WebSphere Message Broker solutions in a simple way using modern 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 not 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 are 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.
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"
To configure it with your queuemanager, just edit a simple properties file (src/test/resources/wmq.properties)
qmgr.hostName=localhost
qmgr.port=2414
qmgr.queueManager=MB8QMGR
qmgr.channel=SYSTEM.AUTO.SVRCONN
#0 = binding, 1 = client, 8 = first binding, then client
qmgr.transportType=1
Then to test it:
# Use gradlew.bat or gradlew if you don't want to install Gradle
gradle test
Check the results graphically in "build/reports/tests/index.html"
If you prefer, you can actually run it as a JUnit test directly from your IDE instead.
Figure 4 - Start the WMBT with a new workspace and then start from samples
Figure 5 - Choose the "Coordinated Request Reply sample"
Figure 6 - Import and deploy the sample
Figure 7 - Import summary that all went well
Figure 8 - Check that the applications are deployed to the Execution Groups
In case we run into the infamous “works on my machine” syndrome.
Groovy/Grails Tool Suite – version: 3.2.0.RELEASE
------------------------------------------------------------
Gradle 1.4
------------------------------------------------------------
Gradle build time: den 28 januari 2013 kl 3:42 UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ivy: 2.2.0
JVM: 1.7.0 (Oracle Corporation 21.0-b17)
OS: Windows 7 6.1 amd64
Name: WebSphere MQ
Version: 7.0.1.8
CMVC level: p701-108-120224
IBM WebSphere Message Broker
BIP8927I: Broker Name 'MB8BROKER'
Queue Manager = 'MB8QMGR'
Operation mode = 'advanced'
Fixpack capability level = 'all' (effective level '8.0.0.2')
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7601 Service Pack 1 Build 7601
System Model: HP EliteBook 8540w
System Type: x64-based PC
Download, clone or fork from: GitHub wmbtesting
Spock is a testing and specification framework for Java and Groovy applications. Since it is JUnit under the hood, it works fine with many IDEs, build tools and CI servers. Spock at Google Code
The build, test and deployment killer app, bye bye Maven.... Gradle
Lightweight integration framework powered by really nice DSL. Apache Camel
The documentation at Info Center for V8 Test Client
The documentation at Info Center for V8 Default configuration
Java JUnit extensions that I think is great for comparing two XML documents. XMLUnit