Mock or simulate Message Queue (JMS)

24
votes

There is a message(text), which format and content i definitely know.
For now,class in Java,that parses and reads this message from file,is implemented.

In real world, this message will come from Message Queue.

For now I should simulate, mock or generate Message Queue on my local PC for testing purposes.

Java spec(java jms):

JMS provider: A messaging system that implements the JMS specification.
JMS clients: Java applications that send and receive messages.
Messages: Objects that are used to communicate information between JMS clients.

Concerning this specification, i need JMS provider.

JMS client-it's my class that reads message.
Message itself i know.

So the question is how to start message queue?
How can i simulate it programmaticaly from Java code? Can i mock it somehow?

Thanks.

4
javamockingjmsmessage-queueprovider
Why go to all that trouble? Why not just install a local JMS provider on your workstation and use it? You can download open source ones and trial versions of vendor JMS providers. Since it's JMS, any compliant implementation will work for unit testing. - T.Rob
That is i ask, so i need install JMS provider. What could you advise me? thank you - sergionni
Well, I'm an IBMer so I have to suggest the trial of WMQ. :-) But I see you've already found ActiveMQ which you can use for development without it expiring. On the other hand, whatever you use in production would be best to develop on so move to that once you know what it will be. - T.Rob
Easy way to mock a JMS Queue. Refer below website dzone.com/articles/mockrunner-jms-spring-unit - Yallaling Goudar

4 Answers

6
votes

If you use Spring Integration, you can do this pretty easily. It has a very basic, abstract "Channel" implementation. You can create and test your producers and consumers, and when you're ready to move a step further, you just specify a JMS adapter on top of your Channel.

8
votes

To test an application in isolation when the real production JMS provider is not available you can use one of:

  1. JMS mock:
    When testing your applications you can simulate the non-existing dependencies using test doubles. You can use a JMS mock which will simulate the behaviour of a real JMS provider. API simulation tools will allow you to create JMS mocks (just choose a tool that supports JMS, for example Traffic Parrot). Using a JMS mock will allow you for a high level of flexibility during testing. You will be able to test typical production-like test scenarios but also hypothetical situations by setting up your mock to return almost any type of message. You will also be able to simulate different types of errors, which is often hard to do with real JMS providers. Have a look at this introduction video to JMS service virtualization for ActiveMq (service virtualization is a different name for a mock) or this one for IBM MQ. Note, these videos are from Traffic Parrot, but the principle described there will apply to any tool you choose.

  2. JMS provider test instance:
    You can run a JMS provider on your laptop or in one of your test environments and connect your application to it instead of the production provider. When you use open source providers in production like ActiveMQ or RabbitMQ, it should be easy to run one of them on your laptop as well because they are lightweight and free. For IBM Websphere MQ, you can use the free IBM MQ for Developers.

  3. JMS class mock:
    You can use Mockito in unit tests to mock interactions with JMS classes. This solution comes with all the trade-offs of unit testing. For more information on those see testing pyramid.

If you would like to black box test your application, use one of the solutions I have described above.

0
votes

Generally it is a bad practice to mock or simulate an external system, such as JMS. A better idea would be to abstract your logic into a standalone bean, implement a delegation layer that would bridge JMS with your bean. With such design you can test your bean in isolation from JMS and then have system test that would test the whole integration with real JMS system.

As for in-process JMS you can look at SomnifugiJMS.

-2
votes

Generally I agree with Eugene Kuleshov. But if you still need such mocking I'd suggest you to use BlckingQueue from java.util.concurent package. I think it is not a big problem to wrap it with javax.jms.Queue interface. BTW it is a good idea for some kind of open-source project.