Contract Testing और वह जो यह जानबूझकर नहीं जाँचता

Contract testing क्या जाँचता है

यह कि दोनों पक्ष जिस shape की अपेक्षा करते हैं, वह एक ही shape है। Field के नाम, types, required और optional, status codes। अगर कोई producer ऐसा field हटा देता है जिस पर कोई consumer निर्भर है, तो contract testing रात के तीन बजे नहीं, build time पर ही fail हो जाता है।

जिस system में कई services हों और deployments स्वतंत्र हों, वहाँ यह वाक़ई मूल्यवान है और end-to-end integration environments के मुक़ाबले कहीं सस्ता है।

यह जानबूझकर क्या नहीं जाँचता

• क्या value सही है। सही shape वाला response, जिसमें total गलत हो, फिर भी हर contract पर खरा उतरता है।

• क्या flow काम करता है। हर call अपने contract पर खरी उतर सकती है, जबकि पूरा sequence एक बेतुका नतीजा देता हो।

• user को क्या दिखता है। Contracts services के आपस में बात करने के बारे में हैं। product को किसी ने खोला तक नहीं है।

यह कोई आलोचना नहीं है। जो contract test values जाँचे, वह data से जुड़ जाएगा और लगातार टूटता रहेगा — ठीक वही चीज़ जिससे बचने के लिए contract testing बनाया गया था। इसका सीमित होना ही इसकी ख़ूबी है।

किस failure mode पर नज़र रखें

कोई टीम contract testing अपनाती है, integration failures रुक जाती हैं और भरोसा बढ़ता है। छह महीने बाद production में कुछ टूटता है जो हर contract test पास कर चुका था, क्योंकि shape सही था और behavior गलत। लोग आमतौर पर यही सबक निकालते हैं कि contract testing नाकाम रहा — और यह गलत सबक है।

Contract testing ने अपना काम किया। कमी यह थी कि behavior को कोई जाँच ही नहीं रहा था, और contract layer की कामयाबी ने उस कमी को और छिपा दिया।

इसके साथ क्या होना चाहिए

चल रही services के ख़िलाफ़ functional verification: क्या calls का sequence सही नतीजा देता है, क्या error paths ठीक से व्यवहार करते हैं, क्या authorization टिकता है। यह एक अलग layer है और यह उन सवालों के जवाब देती है जो contracts नहीं दे सकते।

इन जाँचों को sessions, calls के बीच capture की गई values, क्रम और cleanup संभालने होते हैं — इन सबको कवर करता है API testing documentation।

अगर आप कुछ भी install नहीं करना चाहते, तो dashboard यही काम करता है। command line और जो कुछ कर सकती है, वह सब कवर करता है CLI repository।

Consumer-driven, और यह आमतौर पर क्यों जीतता है

दोनों तरीकों में फ़र्क़ इस बात का है कि contract कौन लिखता है, और यह फ़र्क़ तुरंत नहीं, एक साल बाद दिखता है।

Producer-driven contracts यह दर्ज करते हैं कि service क्या देने का इरादा रखती है। यह उपयोगी है और आमतौर पर ज़रूरत से ज़्यादा उदार होता है: contract पूरे response का वर्णन करता है, उन fields समेत जिन्हें कोई consume ही नहीं करता। फिर बिना इस्तेमाल वाले fields में breaking changes भी build को fail कर देते हैं, और टीमें contract failures को नज़रअंदाज़ करने लगती हैं — जिससे पूरा मक़सद ही ख़त्म हो जाता है।

Consumer-driven contracts यह दर्ज करते हैं कि हर consumer असल में क्या पढ़ता है। contract छोटा होता है, failures असली होती हैं, और एक वाक़ई काम का by-product मिलता है: इसका सटीक नक़्शा कि कौन-सा field किसके लिए मायने रखता है। यही नक़्शा producer को भरोसे के साथ कुछ deprecate करने देता है — और असल में सबको यही चाहिए था।

कौन कहाँ चलता है

Contract tests build time पर, तेज़ी से और हर commit पर, क्योंकि उनकी पूरी क़ीमत integration से पहले shape drift पकड़ने में है। Behavioral verification किसी deployed environment के ख़िलाफ़, हर pull request पर।

Trigger, mechanism से ज़्यादा मायने रखता है। इसे अपने deployment event से जोड़ देने का मतलब है कि हर बदलाव की जाँच होती है, बिना किसी के तय किए; GitHub App यह काम dashboard से करता है, और GitHub Actions का एक step इसे आपके workflow के भीतर से करता है।

TestSprite किन सवालों के जवाब देता है जो contracts नहीं दे सकते

क्या values सही हैं और क्या sequence सही नतीजा देता है। यह चल रही services को उनके interfaces के ज़रिए चलाकर देखता है, इसलिए वह response भी पकड़ में आ जाता है जो हर contract पर खरा उतरता है लेकिन जिसमें total गलत है।

असली कमी multi-step flows में है। Integration Tests ऐसी calls को जोड़ते हैं जहाँ एक response अगली को feed करता है, और Dependency Chains इस आधार पर सुरक्षित क्रम निकालते हैं कि हर case को क्या चाहिए और वह क्या पैदा करता है। Auto-Authentication पूरे run में sessions को ज़िंदा रखता है, Dynamic Variables calls के बीच values ले जाते हैं, Dependency Chains इस आधार पर execution order तय करते हैं कि हर case को क्या चाहिए और वह क्या पैदा करता है, और Auto-Cleanup ठीक वही हटाता है जो run ने बनाया था।

नतीजा दो ऐसी layers हैं जो आपस में नहीं टकरातीं: contracts जो build time पर, सस्ते में और हर commit पर shape drift पकड़ते हैं, और behavioral verification जो सही होने के उन सवालों को पकड़ता है जिनके प्रति contracts जानबूझकर अंधे हैं।