Our largest hurdle in deploying a MicroService was the Integration Testing stage. Just one incompatible API was enough to break the integration environment and block the path to production for all services. While adopting OpenAPI helped address some of the communication gaps in API specs between teams, the deviations during implementation continued to persist. We needed an approach that changed the way teams collaborated on API Specs and also remove the need for integration testing. To fill this need we came up with Contract Driven Development which consists of 1. Contract as Test - Contract (Example: OpenAPI) translated to Test Scenarios against the API implementation. Ensures that Provider (API implementation) adheres to Contract. 2. Smart Service Virtualisation - Verify Stub Data against OpenAPI Spec. Ensures the Consumer (API Client) is compatible with Provider's Contract. 3. Backward Compatibility Testing - OpenAPI vs OpenAPI (no code) to check if versions are backward compatible. Helps teams analyse if a change will break integration. Takeaways: 1. Issues with Integration Testing - The problem statement 2. Executable API Specifications - The role of API Specification Standards in eliminating Integration Tests 3. What is Contract Driven Development? Metrics to understand ROI Target Audience - CTOs / Heads of Engineering / Technology Leaders, Senior Engineers Pre-requisites - API Design Basics, Backward Compatibility, Service Virtualisation, Experience with Contract testing will be a bonus Other talks at this conference 🚀🪐 https://www.conf42.com/im2022 — 0:00 Intro 1:40 Talk