Didn't I just post Use Caching Service as Mocked Microservices? Yes, that post is basically saying that instead of each test case/suite starts its own mocked HTTP server, sets expectation, sends request to it then shuts it down, as a side-product, a caching service can be use as an alternative.
The idea behind is, client calls dependency services in test environment in the same way it calls dependency servies in production environment. How about we go one step further, always call a real service instead of its mocked version?
This used to be hard for monolithic architecture. With shifting to microservices, it's just a matter of few more deployments, a service can provide test / staging / UAT environments to clients. This removes client's burden
to set up and tear down test fixtures, so that test code can reuse
production application context configuration, if you use Spring
Framework. But that's not all.
The biggest benifit in my opinion is, it removes the grey area of responsibility between service provider and consumer. Who's job it is to update a mock service's behavior when the real service changes its behavior? Just imagine how many times your unit tests pass but still fail in
integration test or production, simply because the real service now returns B, but your mocked
service still returns A.
Better communication within team doesn't solve this problem, real-time communication between service consumer and provider does.
No comments:
Post a Comment