Forum Discussion

thePantz's avatar
thePantz
Contributor
5 years ago

AMQP: Verify that no messages are on a queue

Hello,

 

I'm trying to write a test case where the expected result is that a message was NOT queued.

The AMQP Recieve step will fail once the timeout is reached so I cannot perform a verification that no message was recieved

 

Does anyone have experience with this issue? I'm not sure how I can verify this.

 

Thanks

  • Hello,

     

    The system under test uses RabbitMQ. Unfortunately RabbitMQ does not support JMS... only AMQP.

    After further research I've decided to use RabbitMQs Java Client API to verify this.

     

    I also found some useful SoapUI examples on RabbitMQs github.

     

    I will do something like this:

    import com.rabbitmq.client.*
    
    
    String QUEUE_NAME = testRunner.testCase.testSuite.getProperty("queue_name")
    
    ConnectionFactory factory = new ConnectionFactory()
    // uncomment to change defaults
    //factory.setUsername("guest")
    //factory.setPassword("guest")
    //factory.setVirtualHost("/")
    //factory.setHost("localhost")
    //factory.setPort(5672)
    Connection connection = factory.newConnection()
    Channel channel = connection.createChannel()
    
    channel.queueDeclare(QUEUE_NAME, false, false, false, null)
    
    String message
    Consumer consumer = new DefaultConsumer(channel) {
      @Override
      public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body)
          throws IOException {
        message = new String(body, "UTF-8")
        log.info " [x] Received '$message'"
      }
    }
    channel.basicConsume(QUEUE_NAME, true, consumer)
    
    // Wait for async call to finish int stop = 0 while(message == null && stop++ < 20) { log.info " [*] Waiting for messages." sleep 500 }

    //Check that message should still be null after waiting for Async
    assert message == null
    channel.close() connection.close()
  • nmrao's avatar
    nmrao
    Champion Level 3
    May be you want to raise a support request to find if the use case is supported by the tool or not.

    Which JMS vendor? Doesn't matter any ways, I guess.
    Hope, you are able to get over with positive cases.

    • thePantz's avatar
      thePantz
      Contributor

      Hello,

       

      The system under test uses RabbitMQ. Unfortunately RabbitMQ does not support JMS... only AMQP.

      After further research I've decided to use RabbitMQs Java Client API to verify this.

       

      I also found some useful SoapUI examples on RabbitMQs github.

       

      I will do something like this:

      import com.rabbitmq.client.*
      
      
      String QUEUE_NAME = testRunner.testCase.testSuite.getProperty("queue_name")
      
      ConnectionFactory factory = new ConnectionFactory()
      // uncomment to change defaults
      //factory.setUsername("guest")
      //factory.setPassword("guest")
      //factory.setVirtualHost("/")
      //factory.setHost("localhost")
      //factory.setPort(5672)
      Connection connection = factory.newConnection()
      Channel channel = connection.createChannel()
      
      channel.queueDeclare(QUEUE_NAME, false, false, false, null)
      
      String message
      Consumer consumer = new DefaultConsumer(channel) {
        @Override
        public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body)
            throws IOException {
          message = new String(body, "UTF-8")
          log.info " [x] Received '$message'"
        }
      }
      channel.basicConsume(QUEUE_NAME, true, consumer)
      
      // Wait for async call to finish int stop = 0 while(message == null && stop++ < 20) { log.info " [*] Waiting for messages." sleep 500 }

      //Check that message should still be null after waiting for Async
      assert message == null
      channel.close() connection.close()
  • richie's avatar
    richie
    Community Hero
    Hi @thePanz,

    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

    Ta

    Rich