Hi Carl, and what do you think about the following scenario? Precondition: There's a JUnit test for testing the invocation of queue.purge() method.
- Qpid starts; - QMan starts; - Test case starts : using standard JMX interface it registers itself as a notification listener of QMan and wait... - Qpid sends a content information message (to QMan) about a queue instance; - QMan store that data in raw format (he has not yet the queue class definition) and requests to Qpid schema for class queue; - Qpid sends a schema response message; - Qman builds the class definition, uses the previous incoming data to create the queue object instance and emit a JMX notification to inform regoistered listeners about that. - Test case receives the notification and get (via QMan JMX interface) the current number of messages on that queue; - Test case invokes on QMan the purge() method of the queue instance and wait; - QMan send a method request message to Qpid; - Qpid invokes the method and sends a method response message; - QMan receives the method response message and emit another JMX notification to inform registered listeners. - QMan receives the content information message containing data updates for queue, updates the object and emit another JMX Notification - Test receives notification and check the result; The JUnit Test could be decorated too with JUnitPerf to run a timed test in order to ensure that all what described above is performed under a certain amount of time... Of course It's still not a complete idea but I think that there's something of interesting on that... The interesting thing is that you could have differnet listeners than JUnit Test used for listening QMan events. So for example you could create a separate module that is registering as a QMan listener and, using something like JBoss Rules, could define configurable rules for detecting threshold conditions, alerts for QMF events and therefore determining an output channel (SMNP Traps, Email, SMS, I don't know....) Regards, Andrea 2008/10/31 Andrea Gazzarini <[EMAIL PROTECTED]> > Yes Carl,I agree...what do you think about that? > http://clarkware.com/software/JUnitPerf.html > > I used it in my previous project and that was great! > Regards, > Andrea > > 2008/10/30 Carl Trieloff <[EMAIL PROTECTED]> > > Andrea Gazzarini wrote: >> >>> Hi all, >>> Actual bundle of QMan has only "offline" unit test that are running tests >>> again isolated "components" of QMan. That means that in order to see >>> those >>> tests running you don't need to have QMan and / or Qpid running. This is >>> good for development stage, allowing a (moreless) test-driven development >>> and therefore a flexible code but in order to see that all is working >>> (Test >>> --> QMan --> Qpid) we need to add tests against a runnning QMan connected >>> to >>> a broker. I'm thinking about that...I already coded some tests but it's >>> an >>> hard work because the asynchronous nature of the interaction between QMan >>> & >>> Qpid. Probably QMan will be extended to support JMX notifications. I'm >>> thinkng about that so I'm not sure but from a test perspective should be >>> cool if you could register a test as a listener of QMan notifications and >>> in >>> that way you will be informed about object creations, events, method >>> invocations and all what you need to run your verifications. If you some >>> kind of idea feel free to suggest... Regards, Andrea >>> >>> >>> >> >> yes, the question is how to prove all the function interop in a clean and >> automated way. >> >> I expect you will need a time based test, you know an update will be >> reported back with-in >> the interval configured on the broker. You can set that to 1 sec in the >> script, and have the >> test wait say 5sec max before reporting it as failed. >> >> Carl. >> > >
