Functions should, ideally return something. It makes them easier to test.
Same for services in a service architecture.
Bosh!
Chasing The Dragon
Consider a component in your software where you make a request, and it handles that request by doing some processing and then passing the data to the next component for onward processing.
This might be at code level, or it may be your microservices, linked together by REST calls or queues. The problem is still the same.
While there are very good reasons why the knowledge of the orchestration might want to be hidden from some caller, from a testing point of view, if you send a message into the front of a chain of components, and want to see if things are working correctly, the answer is running away from the place where you started the test.
Before you know it, you have to black-box test the world, or provide stubs galore for any test you do.
This is most likely an anti-pattern if it’s the ONLY pattern.
At the lower tiers of the test pyramid, we want to be able to test the request/responses of our services pretty easily. This is most easily done by returning things.
It’s a Design Problem
These choices are a question of how you choose to design the software. At the line of code level, it’s a question of whether you write functions that return things. At the service level, it’s a question of where you put the control – everywhere, or in some central controller which calls a service and with its answer calls the next.
The general rule to use is:
If you modifying the design to make it much easier to test, more often than not, you’re making it a better design overall.
That’s not always true. But when it is, it’s monumentally true!
Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: Chasing The Dragon Opinions expressed by Java Code Geeks contributors are their own. |
