non intrusuive Integration testing

Question

I am writing integration tests for a messaging system.Most of the tests collect counts on the messgaes and their various code-paths end-to-end, at various stages of the flow. The tests I have currently have become far too intrusive in that I have many public static AtomicIntegers in these messaging components - I increment them on processing message - the tests then assert on these counts.

The worse part is that I will have to remove these counters when deploying to prod- something that is prone to add bugs.

How do I design my tests such that I get the counts of the messages passing through these components without actually requiring to stuff-in counters all over my classes ? I was thinking of sub-classing the real components and overriding the methods , and moving the counters in the subclass methods - and using these subclasses in my tests - any other thoughts on better design ?

Answer 1

Scattering your code with static AtomicIntegers used only in tests is certainly a bad idea. Here are few approaches I would recommend:

• use jmx or other monitoring mechanism available in your middleware to read the messages count in non-invasive way

• add possibility to install listeners in all your components. In production environments use null or null object pattern while in tests install some simple listeners to count invocations/messages. di will help you.

• use aop or other instrumentation technology, similar to above.

• test side effects and output! Do not make assumptions on exact messages in the flow, just see whether the overall result is correct. This way your tests are much more flexible and focus on what is being tested. Unfortunately when something breaks debugging will take more time.

Answer 2

I had to deal with the exact similar scenario some time ago. I had several components processing some messages and then passing them to other components. I came up with this design:

• Every component implements an interface that has notify method used to notify and pass received messages to other components
• Every component holds a list of other components that need to be notified when a message is received
• In your tests, all what you have to do is to create a dummy processor that implements the interface defined above and register in all your components. This way the dummy processor gets notified whenever a new message flows in your system. While in production, there won't be dummy processors and that should make your code good for test and production releases.