We all know the importance of unit tests and why every developer should be writing them. Unit tests are a good means to verify the smallest functionality that contributes toward building larger systems.
However, testing microservices is not a routine affair like testing a monolith, since one microservice might interact with a number of other microservices. In that case, should we utilize the calls to the actual microservices to ensure that the complete workflow is working fine? The answer is no, as this would make developing a microservice dependent on another piece. If we do this, then the whole purpose of having a microservice-based architecture is lost. In order to get around this, we will use the mock-and-stub approach. This approach not only makes the testing independent of other microservices but also makes testing with databases much easier since, we can mock database interactions as well.
Testing a small isolated functionality with a unit test or testing a component by mocking the response from an external microservice has its scope and it works well within that scope. However, if you are already asking yourself the question about testing the larger context, then you are not alone. Integration testing and contract testing are the next steps in testing microservices.
In integration testing, we're concerned about external microservices and communicate with them as part of the process. For this purpose, we mock external services. We take this further with contract testing, where we test each and every service call independently and then verify the response. An important concept worth spending time on is consumer-driven contracts. Refer to Chapter 4, Testing Strategies, to study this in detail.