API Mocking with Low Effort is Critical for Scaling Service Testing
Most applications today are architected as a collection of API-driven services with ever-increasing variety and complexity of API interactions. This has spawned an additional burden of “service testing” for engineering teams.
Service tests can test each service in isolation. Each service test issues a request and compares the actual response (or elements within the response) with the expected response. All egress requests to upstream services are mocked for the test. Thus, service tests are run in isolation for each service, and potentially on a developer’s laptop. As Martin Fowler articulated, service tests are good for early (even pre-submit) validation of integration with other microservices – validating new functionality as well as identifying regressions in existing functionality.
Service testing requires developers to create and maintain mocks for each of the egress API requests.
API Mocking Takes Significant Developer Effort
The main friction to the adoption of service testing is that API mock creation and maintenance takes significant developer time and effort.
Creating mock requests and responses is a tedious task for developers.
Developers must create multiple mocks for each egress API to ensure that the variety of scenarios encountered in production are represented in these mocks.
When the API of a producer service changes, developers must update the corresponding mock requests and responses.
While the benefits of shifting left with early service testing are attractive, the costs can be significant due the effort necessary to create and maintain API mocks at scale. As result, development organizations must choose between investing the effort necessary to scale up service testing, or continue to rely on full integration testing which is usually done much later in the SDLC.
Ideal API Mocking Solution for Service Testing
What do developers need so that they can reliably and efficiently build service tests at scale, comparable to that of unit tests? Developers must be able to:
Create API mocks for their service tests with very little effort; in particular, they shouldn’t be expected to handcraft requests and mock responses.
Simulate different API mock responses for egress API requests. This is critical to test negative scenarios where the producer service may throw different types of errors or a 404.
Use the API mocks for testing changes to a service locally on their laptop before submitting their code changes.
Use producer API mocks when service tests run in the CI pipelines.
Update API mocks for producer services with little effort. APIs evolve continuously. Whenever a producer API changes, the corresponding requests and responses of all mocks for that API must be updated, and versioned. The effort required for updating such mocks must be very low; otherwise, the update process would become a bottleneck rendering the service tests not very useful.
At Mesh Dynamics, we are working on addressing these challenges. If you are interested in such a solution for creating service tests easily with auto-created API mocks, please contact us at firstname.lastname@example.org.