When a software engineer needs to integrate two systems via a single interface, the following process is generally used:
It is obvious that this approach is not sustainable when using a microservice architecture model. If the system is divided into small services, a large number of interfaces are created and integration is no longer workable under the aforenamed method. Added to this comes the circumstance that a high level of test automation is a decisive criterion for continual software deployment. This can only be attained by executing the interface tests in an automated manner as a component of the build pipeline (continuous integration CI / continuous delivery CD). There are two methods for the integration of interface tests:
The core idea behind CDC is that the service consumer defines the requirements for the service provider’s API. Each API user concludes a contract with the service provider laying out the requirements on the API.
In the case illustrated in the figure, Service Consumer A needs resource attributes x and y; Service Consumer B requires attributes x and z. Thus, the service provider renders an API with attributes x, y, and z.
For CDC, technical frameworks exist that can be used to create the contracts and ensure service providers and service consumers comply with the agreements. These tests are automated and can be integrated in CI / CD. That makes it possible to reconcile the two methods laid out above. With low infrastructure demands, the pipeline provides swift feedback (fail fast), and yet production is still simulated and the communication between the services is tested. Two prominent representatives for CDC frameworks are Spring Cloud Contract and Pact. The following Groovy file shows a sample contract based on the Spring Cloud Contract:
For implementation, the simplest Spring Cloud Contract variant is managed in a provider source code repository (like git). The procedure for extending a contract between service consumer and service provider is then broken down as follows:
- Service consumer
The consumer clones the service provider’s repository and can generate a local stub server using a build (e.g. in Maven). It can now switch to offline mode and develop and test changes locally. It subsequently creates a merge request.
- Producer phaseIf the service provider accepts the changes, it will write the missing implementation and merge into the master. The CI / CD pipeline loads the stubs into an artifact repository (e.g. Nexus).
- Service consumer
It can now switch back to online mode, load the stubs out of the artifact repository, and test using the CI / CD pipeline.
When CDC tests are being used for testing microservice interfaces in an agile development project, both advantages and disadvantages crystallize.
CDC tests supply additional value when deployment is restricted to service consumers and service providers obtaining a mutual understanding of queries and responses for an API (endpoint, attributes). CDC tests should not be used for business logic.