| Author |
Message
|
| tbt102 |
 Posted: Sun Jul 13, 2003 2:50 am Post subject: Automated regression testing tools and/or techniques. |
 |
|
Apprentice
Joined: 21 Apr 2003
Posts: 28
|
Hi all,
Are there any automated regression testing tools and/or techniques for WMQI?
I realize that every project/flow is different but I'm hoping for something generic that will assist.
Thanks in advance for any help. |
|
| Back to top |
|
 |
| zpat |
| Posted: Sun Jul 13, 2003 11:55 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The free RFHUTIL program (support pac) is very useful as it can copy files to messages and vice versa.
Testing MQSI essentially just means replaying messages in and comparing output messages out. Therefore anything that can covert files to messages (and vice versa) will allow use of standard file comparison programs.
CommerceQuest make an extension to Load Runner - call MQTester. |
|
| Back to top |
|
|
| lung |
| Posted: Sun Jul 13, 2003 5:24 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
| zpat wrote: |
| The free RFHUTIL program (support pac) is very useful as it can copy files to messages and vice versa. |
The SupportPac is IH03.  |
|
| Back to top |
|
|
| JLRowe |
| Posted: Mon Jul 14, 2003 7:12 am Post subject: JUnit |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
| If you know java then check out Junit. I have used it to write unit tests that submit a message and then check the response from each output queue. There is an extension called DBUnit, that allows you to seed (populate a table with known contents) a database and check the results. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Jul 15, 2003 3:00 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
to verify translations still work, i.e. when moving to another release of a component (broker, database, etc) we setup a simple procedure with files and directories.
IN directory contains input files say format1.txt
OUT directory will get the output format from the broker say format1.out
VERIFIED directory contains verified output from the broker say format1.ver
We modified the sample amqsput and get version that puts the filename say format1 in the mqmd, then when the message gets back onto the queue (from the broker) we do a get and put the message into the file with the name from the mqmd.
After all messages are sent through the broker a compare is done of the files in the OUT and VERIFIED directories. This will point you to errors in seconds rather then hours and it is very simple...
So when adding a format, you add the input to IN, run the file through the broker, verify the output and copy the file from the OUT to the VERIFIED directory. |
|
| Back to top |
|
|
| m.schneider |
| Posted: Mon Jul 14, 2008 10:29 pm Post subject: |
|
|
Centurion
Joined: 10 Apr 2007
Posts: 132
Location: Germany
|
Has someone the code for automated testing with JUNIT?
Which tool is best suited for automated testing? MA0T or JUnit or are there any other good tools?
Thx |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jul 15, 2008 12:20 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Its all down to two things
- Personal Choice
- Environment
The scenario that Michael Dag presented is great for WMQ Messages. It is repeatable, verifyiable and auditable and is also Simple and Extensible.
If your system is lots of J2EE, WebServices, SOAP, HTTP etc then this approach may not be practical.
If you make the testing methodology complex then the less likely toy are to get meaningful results from it as doubts about the testing procedure itself can obscure the real results.
If you can, use tools/methods that follow the KISS principle. You won't regret it.
_________________
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 |
|
|
|
|
