Mock or simulate Message Queue (JMS)

Question

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 wor

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.