पूरे सिस्टम को खड़ा किए बिना आप कैसे टेस्ट करते हैं कि दो services अब भी साथ काम करती हैं?

contract testing इस्तेमाल कीजिए। consumer बताता है कि वह कौन सी requests करता है और response के किस आकार पर निर्भर है, वह उम्मीद एक contract के तौर पर प्रकाशित होती है, और provider उसे अपने ही pipeline में जांचता है। तब दोनों पक्ष अलग अलग और तेजी से टेस्ट करते हैं, और तोड़ने वाला बदलाव किसी साझा environment में दिनों बाद दिखने की जगह provider के build को फेल कर देता है।

पूरे end to end environment मुट्ठी भर services से आगे टिकते ही नहीं। वे धीमे हैं, उनमें हर टीम का ताजा build एक साथ ठीक चाहिए, और कुछ लाल होने पर पहला सवाल हमेशा यही होता है कि यह असली defect है या environment। contract testing इससे बचकर निकलती है। consumer provider के एक local stub के खिलाफ टेस्ट लिखता है, और वे बातचीत एक contract के तौर पर दर्ज हो जाती हैं: इस request के लिए, मैं इन types वाले इन fields पर निर्भर हूं। वह contract प्रकाशित होता है, और provider का अपना pipeline उसे असली provider implementation पर दोबारा चलाता है। अगर कोई किसी field का नाम बदलता है या type बदलता है, तो उनका build फेल होता है, उनके ही repo में, बदलाव के मिनटों बाद, और message बताता है कि कौन सा consumer टूट रहा है। पूरी कीमत यही है: feedback वहीं गिरता है जहां बदलाव हुआ था। जो बारीकी कहने लायक है वह यह कि contract सिर्फ उतना कवर करता है जितना consumer सच में इस्तेमाल करता है, provider की पूरी सतह नहीं, इसलिए यह provider के अपने functional टेस्ट की जगह नहीं लेता, और यह कारोबारी सहीपन नहीं, आपस में मेल जांचता है। उन चंद यात्राओं के लिए मैं अब भी एक छोटा end to end suite रखता हूं जिन्हें सच में services के आर पार साबित करना जरूरी है।