| Author |
Message
|
| saipavan |
 Posted: Fri May 06, 2011 9:35 am Post subject: unit testing in wmb |
 |
|
Novice
Joined: 26 Oct 2010
Posts: 14
|
| how to do unit testing in wmb |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri May 06, 2011 9:40 am Post subject: Re: unit testing in wmb |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| saipavan wrote: |
| how to do unit testing in wmb |
Same way you do unit testing for any other development. Push data in one end of the flow with an appropriate tool and review the results with an appropriate tool.
For instance, if you have a flow fronted by a SOAPInput node you could use SoapUI to push a message in.
Simple.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| saipavan |
| Posted: Fri May 06, 2011 9:41 am Post subject: |
|
|
Novice
Joined: 26 Oct 2010
Posts: 14
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 06, 2011 9:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Presumably this means you've got the environment / local environment & database questions from your previous posts sorted out and now have a flwo to test?
It's progress.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri May 06, 2011 9:42 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 06, 2011 9:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Enough. I'm sure if the OP could afford the training, or could talk his management into it, he'd have taken it.
(This in no way diminishes my support of formal training for WMB as a good way forward, nor my belief that asking simple questions on this forum every step of the way is a bad thing. Just that there's a limit to how many times you can bang on about it.)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 06, 2011 9:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Though there does appear to be no limit how many broad based questions can be posted in lieu of training... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 06, 2011 10:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Unit testing of Message Broker flows that start with MQInput nodes is performed by creating a set of test messages that represent different test cases.
Then some tool is used to put these messages onto the relevant MQ queues.
Like, for example, the Message Broker Test Client that ships with Toolkit. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 06, 2011 10:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
Then some tool is used to put these messages onto the relevant MQ queues.
Like, for example, the Message Broker Test Client that ships with Toolkit. |
If the flow is fronted by an MQInput node.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| saipavan |
| Posted: Sat May 07, 2011 12:04 pm Post subject: |
|
|
Novice
Joined: 26 Oct 2010
Posts: 14
|
| can i know which tools we will use |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat May 07, 2011 12:50 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| saipavan wrote: |
| can i know which tools we will use |
Any tool you want.
Including the Message Flow Test Client that ships with Toolkit. |
|
| Back to top |
|
|
| goffinf |
| Posted: Sun May 15, 2011 3:41 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| saipavan wrote: |
| can i know which tools we will use |
We use JUnit to drive flows that start with MQ or HTTP and at any point in the flow we are able to drive results back to junit Test cases which contain assertions (typically using XMLUnit, although we are not limited to XML formats).
A typically unit test would involve creating individual test cases for every Compute node, filter node and custom procedure/function and then some end2end tests that assert against the output of a complete execution paths (which can be adjusted to ensure as much coverage as you want). We can easily target specific nodes within a flow.
We can establish the contents of each/all of the input trees prior to executing a test (body, environment, local env and exception list) and harvest any/all of the output trees in the message against which we run our junit assertions.
Our preference is to use a single test framework (junit in this case) rather than a variety of different tools since this helps to consolidate our skills base and the typical testing patterns we want our devs to follow.
All of the above is conducted by devs on their local machines and must all pass before code is migrated to server environments. We can execute the same tests on remote servers quite straight-forwardly.
In addition we would normally have a battery of other regression type tests that are more black box in nature.
More recently we have begun tying all of this together using CI, so that on check in of source code to the repository, all code is compiled, deployed, unit tested and reports emitted on success/failure.
So it's all doable, and by an large you can leverage existing frameworks without having to roll your own.
Fraser. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun May 15, 2011 5:41 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| goffinf wrote: |
We use JUnit to drive flows that start with MQ or HTTP and at any point in the flow we are able to drive results back to junit Test cases which contain assertions (typically using XMLUnit, although we are not limited to XML formats).
|
This all means:-
You and your organisation is going to have to spend some time (and thus money) deciding upon the tool or tools that is best suited for the mix of data and flows in your org.
There is no panacea. No OOTB box tool that will do comprehensive Unit testing of all data types & transports without a good deal of customisation.
I know of one large company that invested more than 6 man months of time to setup a comprehensive test suite for their broker setup. They have a particularly diverse set of data types. The have it all in pace now and do continuious testing 24/7.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon May 16, 2011 12:47 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Look at support pac IH03 (rfhutil/c) for a simple tool to load MQ message test data to/from files.
You could compare the resulting output using various free file comparison tools. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon May 16, 2011 4:32 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| goffinf wrote: |
| saipavan wrote: |
| can i know which tools we will use |
We use JUnit to drive flows that start with MQ or HTTP and at any point in the flow we are able to drive results back to junit Test cases which contain assertions (typically using XMLUnit, although we are not limited to XML formats).
A typically unit test would involve creating individual test cases for every Compute node, filter node and custom procedure/function and then some end2end tests that assert against the output of a complete execution paths (which can be adjusted to ensure as much coverage as you want). We can easily target specific nodes within a flow.
We can establish the contents of each/all of the input trees prior to executing a test (body, environment, local env and exception list) and harvest any/all of the output trees in the message against which we run our junit assertions.
Our preference is to use a single test framework (junit in this case) rather than a variety of different tools since this helps to consolidate our skills base and the typical testing patterns we want our devs to follow.
All of the above is conducted by devs on their local machines and must all pass before code is migrated to server environments. We can execute the same tests on remote servers quite straight-forwardly.
In addition we would normally have a battery of other regression type tests that are more black box in nature.
More recently we have begun tying all of this together using CI, so that on check in of source code to the repository, all code is compiled, deployed, unit tested and reports emitted on success/failure.
So it's all doable, and by an large you can leverage existing frameworks without having to roll your own.
Fraser. |
Wow! You are on-the-ball Fraser.
Could you post some example code that looks at the tree between nodes? I am guessing this is how you do: "at any point in the flow we are able to drive results back"
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
