CDCs short for Consumer Driven Contract Tests.
They involve writing test cases for other systems. These systems are the ones that we communicate with. Since their is a contract involved during event driven communication, it is highly imperative to ensure that this contract stays as it is even during feature developments, refactoring or any kind of code development on the other system.
Why we need CDCs
Lets say we our System A and we consume messages from System B using a contract. Since our functionality depends on System A.
We need to ensure that if System B unintentionally changes their code and the contract is affected, they KNOW that System A will fail since it will no longer be able to consume the messages/ event as the contract has been changed.
An effective way to ensure this is to write CDC or tests on our project that will be provided to System B to run. If during development of System B, they change this contract, and try to build it, the CDC by System A will fail and System B will know to rollback changes or to inform System A to take care of that change on our side. Hence, CDC helps to maintain proper communication between multiple Systems ensuring contract changes are properly communicated and maintained.
How to implement?
We write CDCs in our code base as simple as a JAVA Unit Test. These are then be wrapped into a docker image to be easily shared. This docker image can be shared via docker registry. The other System is informed that they have to run this CDC as we are using their contract.
Hence, they on their side, in their build pipeline, pull this docker image from registry and run it. If it runs successfully we know the contract is alive, if not, they need to inform us to incorporate the change.
If multiple Systems our consuming our contract, and we want to change it, we know whom to communicate the change to.
Top comments (0)