Contract-driven development (CDD) is an effective solution for testing contract compatibility between components during the software development lifecycle, especially for microservices. It involves writing and storing API specifications before building applications, which follows a different approach than usual practices and may take time to adopt. CDD builds on and contributes to a strong test pyramid, which requires changes to test composition, strategy, and application architecture to improve component testability. In this article, Hari Krishnan shares his journey of how a large financial services company adopted contract-driven development, starting from their initial skepticism to demonstrating the value and influencing change by getting people to collaborate over API specifications. The article also covers their situation before adoption, the transition from monolith to microservices, and the challenges faced with consumer-driven contract testing. The article concludes with tips on how to start the CDD adoption journey, identify the necessary changes, and convince leadership and others to drive large-scale adoption.
