Introduction

In one of my previous posts, I briefly described the concept of a test message. Today I want to explain it in more detail. The need to keep production systems operational is self-explanatory. It’s the highest priority in all businesses—being able to operate, without doubts about software quality. Users need to trust the system.

Usually, system communication looks like this:

There are multiple systems exchanging information.

If I pay for a book, I trust the banking application to charge me once. That’s one piece. Another critical piece is messaging. All systems exchange messages. Communication between components, processes, and machines requires some kind of messaging schema. In large systems, this is known as integration.

With these two pieces in place, the concept of a test message becomes clear. To keep a system operational, we need to ensure that messages are flowing as intended.

Potential Problem

”If it works, don’t touch it” isn’t said without reason. As long as we’re actively developing a particular integration, we know how it works. We have one interface with another party, and everything is fine.

Problems can arise when one of the systems or a related component (e.g., authentication mechanisms) is updated. It becomes difficult to predict what might break. The obvious solution is to replicate the system in a test environment—but this is often hard or impossible.

Another approach is to update the system, wait for the first message to arrive, and then examine whether everything worked. This is risky, especially for integrations that rarely exchange messages.

There is no silver bullet for this problem.

Test Message

At this point, let me introduce the idea of a Test Message.

A test message does not guarantee logical correctness. That should be verified using other methods. What a test message can do is confirm that the integration is operational.

The general idea is described here: Enterprise Integration Patterns – Test Message

Simply put, one system generates a test message, and another receives it. If you control both systems, it’s easy to filter out test messages. If you’re integrating with a system outside your control, you can intercept the message at your own endpoint.

The simplest solution is to add a flag to the message schema indicating it’s for testing. For domain purists, there’s another simple option: set a property to a known test value, like "TEST_VENDOR" or "TEST_QUOTE_NUMBER", and filter on that at the endpoint.

Once test messages are flowing, it’s valuable to have monitoring in place. Monitoring acts as a sensor to check system health. I’ll cover that in another post.