The most crucial part of software development is testing. It should
ensure us, that our code is correct, works according to given specs,
etc. There are many kinds of tests: unit tests, integration, functional.
In general you should try to test the smallest possible subset of your
code and be able to check the state of the objects after the test.
This seems as rather easy task, but what if you have an integration
end-to-end test to perform? In most cases asserting state in integration
test is rather hard due to multiple systems interoperability. Let's
focus on a specific situation.
What I needed to do the other day was write some integration test for
Jms based system. The processing pipeline is easy:
- fetch object from DB
- process it
- publish on JMS
some other system (X-system) polls JMS:
- if message is found
- fetch it (message disappears from the JMS queue)
- do sth with it
Looks simple but since I didn't have any sane access to the X-system I
wanted to be sure that my object was actually put into the queue. It was
not acceptable to subscribe to the queue and fetch that object in my
test - it would dusrupt the flow of the whole process.
Fortunately I've been using ActiveMQ and since it offers a
thing called Advisory
Messages I've decided to use just them.
What are advisory messages? They are a set of administrative messages
that are generated on a specific event, like message consumption,
message delivery, topic destruction, and many more. Each type of message
is delivered to a separate topic - prefixed with
ActiveMQ.Advisory. Since generation of such messages
may be an overhead in production systems these features are turned off
by default. You need to enable specific type of
advisory message for a specific jms destination. You can do this with
ths configuration change to activemq.xml
As you can see, I've specified which advisories I want enabled. The full
list of available advisories can be found here.
Since I wanted to read messages from that topic I've added the following
configuration to my spring context - there is one destination bean for
inserting messages and one bean for advisory topic.
Thanks to this configuration I've been able to check that my message was
actually delivered to the queue. There've been no need to worry about
race conditions in consuming the message from original queue - if the
X-system read the message, I'd be unable to determine if it has ever
been in JMS at all.
What's not so nice about that:
- advisory messages can be thought of as counters rather than debugging
information
- they don't contain any data that would allow us to match advisory
message to the original message - thou you could correlate by
timestamp
All in all, it's a good tool to have! But perhaps you have some other
thoughts on this subject? How do you test JMS?
