Microservice Testing, or the MiddleMan

I’ve been thinking about Component Testing recently especially in an environment where the components are not necessarily all written in the same language, or you have some convoluted messaging paths through the components.

There are lots of great tools out there for everything but full integration testing. Component level integrations are hard, ideally you want your application to be running as it would in production but you still want to observe all the communication between Components.

How does one simplify the verification of the interactions of the components without having to make heavy modification to the actual code to facilitate testing, or just hitting a service and assuming if the response is correct then you got there in the way you expected to get there?

There is a layer that knows all of this of course, that layer is the network layer. While you are spending time trying to ensure that your components are sending and receiving the correct messages the network is busy delivering all of those messages exactly as they are formatted and between the exact components specified by the sender.

Therefore it stands to reason that a simple middleman would be an ideal solution to the problem of observing message delivery between Components. What that middleman looks like I don’t exactly know, although anyone who has read this blog can probably guess my preferred language for the first attempt.

Not only would an application sitting between all the Components be able to monitor messaging between them. It would also be able to simulate edges (both internal and external) and play a role in mocking or stubbing messaging when used at a non-integration level. With sufficient knowledge about the application under test the MiddleMan could also warn of contract changes and enforce contract integrity between Components.