That's part of the problem with asynchronous messaging along with trying to prove a negative.....there's no response to assert against.
@nmrao i believe is quite knowledgeable with JMS messaging so it's likely he would be able to provide some advice. I've always gotten around messagebroker asynch issues by getting the developers to create additional test harness apis that hook into the queue/topic endpoint (essentially providing a response to assert against). An alternative to this is that ive queried the queue's underlying table when trying to prove when a message has hit the queue, although i dont think this approach will work for your scenario as youre trying to prove the absence of a message hitting a queue.
Until one of the JMS experts (which im not cos i always cheat and use additional test harness apis to enable my testing) responds, can you provide a little more info on your use case?
Whats the purpose of testing this scenario? On your system, what happens to a message that isnt successfully queued.....does it go to a deadletterQ? If a message doesnt hit a queue (and im struggling to see how it couldnt or at least go to a deadletterQ) where does your message go in these circumstances? Is it a worthwhile test? If a message doesnt hit the relevant queue and doesnt go anywhere, surely this is a whole in the functionality? Surely if the document subscriber/trigger is setup on the queue, the document will always hit the queue?
Ok...thats all i got for now, but im sure one of the JMS Q experts might have some ideas
if this helped answer the post, could you please mark it as 'solved'? Also if you consider whether the title of your post is relevant? Perhaps if the post is solved, it might make sense to update the Subject header field of the post to something more descriptive? This will help people when searching for problems. Ta