introduction contract testing with examples
यह संविदा अनुबंध परीक्षण ट्यूटोरियल बताता है कि उपभोक्ता-प्रेरित अनुबंध परीक्षण क्या है, यह कैसे काम करता है और आपको इसे अपने परीक्षण रणनीति में क्यों उपयोग करना चाहिए:
कॉन्ट्रैक्ट टेस्टिंग क्या है?
कंज्यूमर-ड्रिव्ड कॉन्ट्रैक्ट टेस्टिंग एपीआई टेस्टिंग का एक रूप है जो वास्तव में लेफ्ट को सक्षम बनाता है। हमारे द्वारा उपयोग किया जाने वाला अनुबंध उपकरण है Pact.io , और हम ट्यूटोरियल की इस श्रृंखला में बाद में इसके बारे में जानेंगे।
संविदा परीक्षण दो अनुप्रयोगों के बीच एकीकरण को सत्यापित करने की एक विधि है जो स्वतंत्र रूप से परीक्षण करने के लिए पारित किया गया है और देखें कि क्या 'अनुबंध' के साथ मेल खाता है।
एक चुस्त सेटिंग में काम करते हुए, सूक्ष्म परीक्षण वास्तुकला के भीतर अनुबंध परीक्षण अच्छी तरह से फिट होते हैं। इसलिए उदाहरण उस अनुभव पर आधारित होंगे जो हमने इस वातावरण में काम करते समय प्राप्त किया है।
आप क्या सीखेंगे:
- इस अनुबंध परीक्षण श्रृंखला में ट्यूटोरियल की सूची
- उपभोक्ता-चालित अनुबंध परीक्षण
- अनुबंध परीक्षण बनाम एकीकरण परीक्षण
- लगातार एकीकरण
- निष्कर्ष
इस अनुबंध परीक्षण श्रृंखला में ट्यूटोरियल की सूची
ट्यूटोरियल # 1: उदाहरणों के साथ अनुबंध परीक्षण का परिचय [यह ट्यूटोरियल]
ट्यूटोरियल # 2: जावास्क्रिप्ट में एक उपभोक्ता संधि परीक्षण कैसे लिखें
ट्यूटोरियल # 3: पैक्ट ब्रोकर के लिए संधि अनुबंध कैसे प्रकाशित करें
ट्यूटोरियल # 4: पैक्ट कॉन्ट्रैक्ट के साथ पैक्ट कॉन्ट्रैक्ट और कंटिन्युअस डिप्लॉयमेंट को वेरिफाई करें
उपभोक्ता-चालित अनुबंध परीक्षण
शुरुआती बिंदु आपका एपीआई दस्तावेज है जो आपके परीक्षणों का अनुबंध बनाता है, इस बिंदु पर, आमतौर पर, विकास दल एपीआई दस्तावेज़ लेते हैं और विकी दस्तावेज़ (या जो भी आपके संगठन में रहता है, जैसे वर्ड दस्तावेज़) के खिलाफ विकसित होता है।
उदाहरण के लिए, एक वेब एप्लिकेशन जहां टीम-क्रिप्टन द्वारा फ्रंट-एंड विकसित किया जा रहा है और टीम थोरॉन द्वारा एपीआई विकसित किया जा रहा है। परियोजना एक किक-ऑफ मीटिंग के साथ शुरू होती है जहां आवश्यकताओं को प्रस्तुत किया जाता है और टीमों के बीच सहमति होती है।
प्रत्येक टीम आवश्यकताओं को लेती है और कहानियों को परिष्कृत करके बैकलॉग बनाना शुरू करती है। उपयोगकर्ता कहानियों के बाद दोनों टीमों में विकास शुरू होता है, एकीकरण परीक्षण बाद के स्प्रिंट के लिए छोड़ दिया जाता है। जैसा कि टीम क्रिप्टन अतिरिक्त आवश्यकताओं को पाती है, त्रुटि परिदृश्य से संबंधित एपीआई प्रलेखन तदनुसार अद्यतन किया जाता है।
परीक्षण के मामले टीम थोरोन द्वारा प्रलेखन के आधार पर अद्यतन परिदृश्यों से संबंधित हैं।
पहले से ही हम इस प्रक्रिया के साथ कुछ खामियां देख सकते हैं, और मैंने अच्छे भाग्य के लिए कुछ और जोड़ा है:
- API दस्तावेज़ परिवर्तनों को प्रभावी ढंग से संप्रेषित नहीं किया जा सकता है।
- फ्रंट-एंड टीम बैक-एंड सेवा और इसके विपरीत स्टब्स आउट।
- बैक-एंड टीम प्रलेखन के आधार पर एकीकरण परीक्षण मामलों का निर्माण करती है।
- एकीकरण वातावरण पहली बार है जब पूर्ण एकीकरण का परीक्षण किया गया है।
- एकीकरण वातावरण बनाम उत्पादन पर अलग एपीआई संस्करण।
उपभोक्ता द्वारा संचालित अनुबंध परीक्षण के दो पक्ष होते हैं अर्थात् उपभोक्ता और प्रदाता। यह वह जगह है जहां माइक्रोसेवा में परीक्षण के बारे में पारंपरिक सोच चारों ओर फ़्लिप की जाती है।
उपभोक्ता अनुरोधों और अपेक्षित प्रतिक्रिया सहित परिदृश्यों का क्यूरेटर है। यह आपको अनुसरण करने की अनुमति देता है बिस्तर का नियम जो आपके हुक्म में लचीला होना चाहिए, जो आपके एपीआई स्वीकार कर सकता है लेकिन जो भेजा गया है उसमें रूढ़िवादी है। खामियों का हवाला देते हुए सं। 1, 3, और 4, प्रलेखन परिवर्तन उपभोक्ता द्वारा संचालित होते हैं।
उदाहरण के लिए, ऐसी स्थिति में जहां टीम थोरॉन अशक्त मूल्यों को स्वीकार नहीं करने के लिए एक स्ट्रिंग फ़ील्ड बदलती है, उपभोक्ता परीक्षण परिवर्तन को प्रतिबिंबित नहीं करेंगे और इसलिए विफल होंगे। या कम से कम जब तक टीम क्रिप्टन पर बदलाव नहीं किए गए थे।
[छवि स्रोत ]
प्रदाता उपभोक्ता द्वारा उनके 'देव' पर्यावरण के खिलाफ दिए गए परिदृश्यों की पुष्टि करता है। यह आपके माइक्रोसर्विस को लागू करने की अनुमति देता है समानांतर परिवर्तन जो बताता है कि आपको एपीआई कार्यक्षमता का विस्तार करना चाहिए, इसके बाद एक नए संस्करण में माइग्रेट करना चाहिए। वापस दोष नं। 2, अपने स्वयं के परीक्षण आवश्यकताओं के लिए आमतौर पर बैक-एंड टीमों द्वारा बनाए गए स्टब्स अब उपयोग किए जा रहे उपभोक्ता परिदृश्यों पर आधारित हो सकते हैं पैक्ट स्टब सर्वर ।
दोनों पक्षों का बाध्यकारी तत्व 'अनुबंध' है जिसे टीमों के बीच साझा करने की आवश्यकता है। समझौता अनुबंध को साझा करने के लिए सक्षम करने के लिए एक मंच प्रदान करता है पैक्ट ब्रोकर (एक प्रबंधित सेवा के रूप में उपलब्ध है Pactflow.io ) का है।
दलाल उपभोक्ता परिदृश्यों के उत्पादन को संग्रहीत करता है। तब अनुबंध एपीआई के संस्करण के साथ दलाल के भीतर संग्रहीत किया जाता है। यह एपीआई के कई संस्करणों के खिलाफ परीक्षण को सक्षम करता है, इस प्रकार संगतता को रिलीज से पहले पुष्टि की जा सकती है, जैसा कि दोष संख्या 5 में दिखाया गया है।
विरासत प्लेटफार्मों में पैक्ट ब्रोकर को एक अतिरिक्त लाभ उपभोक्ताओं की दृश्यता है। सभी उपभोक्ताओं को एपीआई लेखकों के लिए नहीं जाना गया है, विशेष रूप से यह नहीं कि यह कैसे खपत हो रहा है।
विशेष रूप से एक घटना का जिक्र करते हुए जहां दो एपीआई संस्करणों का समर्थन किया जा रहा था, संस्करण 1 (वी 1) के भीतर एक डेटा मुद्दा था जिससे एपीआई का कारण बन रहा था गंदा डेटा डेटाबेस में।
परिवर्तन एपीआई के V1 में लागू किया गया था और उत्पादन के लिए धकेल दिया गया था, हालांकि, उपभोक्ता उस प्रारूप पर निर्भर करता था जो डेटा समस्या पैदा कर रहा था, जिससे एपीआई के साथ उनका एकीकरण टूट गया।
यह कैसे काम करता है
ऊपर का उदाहरण प्रमाणीकरण प्रवाह दिखाता है, वेब सेवा को संवेदनशील डेटा तक पहुंचने के लिए उपयोगकर्ताओं को प्रमाणित करने की आवश्यकता होती है। वेब सेवा एक उपयोगकर्ता नाम और पासवर्ड का उपयोग करके टोकन बनाने के लिए एपीआई को एक अनुरोध भेजती है। एपीआई एक वाहक टोकन लौटाता है जिसे प्रमाणीकरण हेडर के रूप में डेटा अनुरोध में जोड़ा जाता है।
उपभोक्ता परीक्षण उपयोगकर्ता नाम और पासवर्ड के साथ निकाय पास करके टोकन के लिए एक POST अनुरोध का निर्माण करता है।
परीक्षण के दौरान एक मॉक सर्वर का उपयोग किया जाता है जो आपके द्वारा बनाए गए अनुरोध को मान्य करता है, साथ ही अपेक्षित प्रतिक्रिया के साथ जिसमें इस उदाहरण में टोकन के लिए मूल्य शामिल है।
उपभोक्ता परीक्षण का आउटपुट एक संविदा अनुबंध फ़ाइल उत्पन्न करता है। इसे संधि दलाल में संस्करण 1 के रूप में संग्रहीत किया जाएगा।
प्रदाता तब संधि दलाल से संस्करण 1 खींचता है और उपभोक्ता आवश्यकताओं के साथ अनुरोध और प्रतिक्रिया मैच को सत्यापित करके, अपने स्थानीय वातावरण के खिलाफ इस अनुरोध को दोहराता है।
नियम और जिम्मेदारियाँ
गुणवत्ता आश्वासन (QA) / परीक्षक: Pact.io का उपयोग करके अनुबंध बनाना और परीक्षण परिदृश्य उत्पन्न करने के लिए बीए के साथ काम करना।
डेवलपर: परीक्षणों को बनाने और सतत एकीकरण (CI) में कार्यान्वयन के लिए API को लपेटने में मदद करने के लिए QA के साथ जोड़ी बनाना।
व्यापार विश्लेषक (बीए): परिदृश्यों को बनाना और प्रभावित पक्षों को सत्यापित करने के लिए वास्तुकार के साथ काम करना।
समाधान वास्तुविद् (आपके संगठन में मौजूद नहीं हो सकता है): एपीआई परिवर्तनों को लागू करना और कार्यान्वयन पर बीए के साथ समन्वय करना, उपभोक्ताओं में परिवर्तन का संचार करना (पैक्ट ब्रोकर का उपयोग करना यह समझने के लिए कि यह किस पर चिंता कर सकता है)।
रिहाई प्रबंधन: (हां, मुझे पता है कि यह पुराने जमाने का है, लेकिन अभी भी मेरी दुनिया में मौजूद है): इस विश्वास के साथ कि अनुबंध परीक्षण कवरेज के कारण बदलाव सफलतापूर्वक जारी किए जाएंगे।
पूरी टीम: पैक्ट्स CLI टूल के साथ रिलीज़ को निर्धारित करने के लिए परिणामों को सत्यापित करें कि क्या उत्पादन के लिए धक्का दिया जा सकता है, क्या मैं नियुक्त कर सकता हूँ? ।
अनुबंध परीक्षण बनाम एकीकरण परीक्षण
उत्पादन पर्यावरण को बढ़ावा देने से पहले सिस्टम काम कर रहा है या नहीं, यह प्रमाणित करने के लिए एकीकरण परीक्षण का अस्तित्व है, लेकिन परिदृश्यों को काफी कम किया जा सकता है।
इस का प्रभाव हो सकता है:
- एकीकरण पर्यावरण को जारी करने से पहले तेज़ प्रतिक्रिया।
- एकीकरण पर्यावरण की स्थिरता पर कम निर्भरता।
- कई एपीआई संस्करणों का समर्थन करने वाले कम वातावरण।
- एकीकरण के मुद्दों के कारण अस्थिर पर्यावरण उदाहरणों में कमी।
एकीकरण | अनुबंध | |
---|---|---|
स्पष्ट रूप से पिनपॉइंट विफलता | कई परतें | बहुत आसान |
एपीआई विन्यास | हाँ | नहीं न |
तैनाती की जाँच | हाँ | नहीं न |
एपीआई संस्करण | हाँ | हाँ |
स्थानीय रूप से डिबग करें | नहीं न | हाँ |
पर्यावरण के मुद्दें | हाँ | नहीं न |
प्रतिक्रिया समय | धीरे | तेज |
सबसे पहले, अनुबंध परीक्षण एकीकरण परीक्षण की जगह नहीं लेता है। लेकिन यह संभवतः आपके कुछ मौजूदा एकीकरण परीक्षण परिदृश्यों को बदल सकता है, बाईं ओर शिफ्ट हो सकता है, और आपके सॉफ़्टवेयर विकास जीवनचक्र को तेज़ प्रतिक्रिया प्रदान करता है।
एकीकरण परीक्षण में, आप उस संदर्भ की पुष्टि करेंगे जिसमें API रहता है, जैसे कि पर्यावरण वास्तुकला, परिनियोजन प्रक्रिया, आदि।
इसलिए आप कोर परीक्षण परिदृश्यों को चलाना चाहते हैं जो कॉन्फ़िगरेशन की पुष्टि करेगा, उदाहरण के लिए, एपीआई संस्करण के लिए स्वास्थ्य जांच समापन बिंदु। यह भी साबित कर रहा है कि क्या 200 की प्रतिक्रिया देकर तैनाती सफल रही।
अनुबंध परीक्षण में, आप एपीआई की बारीकियों का परीक्षण कर रहे हैं, जिसमें एपीआई संरचना, सामग्री (उदाहरण के लिए फ़ील्ड मान, कुंजियाँ मौजूद हैं) और त्रुटि प्रतिक्रियाओं से संबंधित किनारे मामले शामिल हैं। उदाहरण के लिए, क्या एपीआई शून्य मानों को संभालता है या वे एपीआई प्रतिक्रिया (एक और वास्तविक उदाहरण) से छीन लिए जाते हैं।
कुछ लाभ (यदि आप पहले से नहीं बिके हैं)
नीचे सूचीबद्ध किए गए कुछ फायदे हैं जो व्यापक व्यवसाय के लिए अनुबंध परीक्षण बेचते समय आकर्षित करते हैं:
- सॉफ्टवेयर की तेज़ तैनाती
- सत्य का एक स्रोत
- सभी उपभोक्ताओं की दृश्यता
- विभिन्न एपीआई संस्करणों के खिलाफ परीक्षण में आसानी।
बार बार पूछे जाने वाले प्रश्न
कॉन्ट्रैक्ट टेस्टिंग को अपनाने के लिए लोगों को मनाने की कोशिश करते समय कुछ सामान्य प्रश्न शामिल हैं:
Q # 1) हमारे पास 100% परीक्षण कवरेज पहले से ही है इसलिए हमें इसकी आवश्यकता नहीं है।
उत्तर: वैसे यह असंभव है, लेकिन अनुबंध परीक्षण में सिर्फ टेस्ट कवरेज के अलावा कई अन्य लाभ हैं।
Q # 2) एपीआई के परिवर्तनों को संप्रेषित करने के लिए यह समाधान आर्किटेक्ट की जिम्मेदारी है।
उत्तर: गुणवत्ता पूरी टीम की जिम्मेदारी है
क्यू # 3) हम एपीआई टीम के लिए परीक्षण परिदृश्य क्यों बना रहे हैं?
उत्तर: एपीआई टीम यह नहीं जानती है कि वेब सेवा कैसे काम करती है, इसलिए इसकी जिम्मेदारी क्यों होनी चाहिए।
क्यू # 4) हमारे अंत-से-अंत परीक्षण अन्य एकीकरण बिंदुओं सहित पूरे प्रवाह को शुरू से अंत तक कवर करते हैं।
fig_cropper.swf कैसे खोलें
उत्तर: सटीक रूप से हम किसी एक चीज़ का परीक्षण करने के लिए परीक्षणों को विभाजित कर रहे हैं और यह आपकी ज़िम्मेदारी नहीं है कि आप उस प्रणाली के अंतिम-से-अंत प्रवाह का परीक्षण करें जिसे आप नहीं जानते कि यह कैसे काम करता है।
Q # 5) किस टीम के भंडार में परीक्षण रहते हैं?
उत्तर: दोनों। उनके भंडार में उपभोक्ता और उनके में प्रदाता। फिर केंद्रीय बिंदु में, अनुबंध उनमें से किसी एक के बाहर रहता है।
बहस
ये तर्क हैं कि जब हमें परीक्षण करने के लिए अनुबंध करने के लिए संक्रमण की बात आती है, तो इसके खिलाफ बहस करना कठिन लगता है:
- स्वैगर प्रलेखन पहले से ही है जो एकीकरण परीक्षण उत्पन्न करने के लिए इस्तेमाल किया जा सकता है।
- एपीआई परिवर्तनों के लिए एक प्रभावी तंत्र के साथ टीमें दोनों फ्रंट-एंड और बैक-एंड सेवाओं के मालिक हैं।
लगातार एकीकरण
यह आपके निरंतर एकीकरण परीक्षण सूट में कैसे फिट बैठता है? जीने के लिए अनुबंध परीक्षण के लिए वांछनीय स्थान आपकी इकाई परीक्षणों के साथ है।
उपभोक्ता परीक्षण एक मॉक सर्वर को स्पिन करता है जिसके लिए परीक्षण के बाहर किसी बाहरी निर्भरता की आवश्यकता नहीं होती है।
प्रदाता परीक्षणों के लिए एपीआई उदाहरण की आवश्यकता होती है, इसलिए स्थानीय एपीआई का उपयोग करके लपेटा जा सकता है इन-मेमोरी टेस्ट सर्वर । हालाँकि, अगर आपके एपीआई को स्थानीय रूप से लपेटना आसान नहीं है, तो पहले जो हमने इस्तेमाल किया है, वह एक ऐसा स्थान है जहाँ हम एक पर्यावरण को बचाते हैं और इस माहौल में कोड को पुल अनुरोध स्वचालित जांच के एक भाग के रूप में तैनात करते हैं।
[छवि स्रोत ]
निष्कर्ष
इस ट्यूटोरियल में, हमने सीखा कि अनुबंध परीक्षण का मतलब क्या है और यह एक माइक्रोसेर बुनियादी ढांचे में कैसा दिखता है, और यह देखा कि यह वास्तविक दुनिया के उदाहरण में कैसा दिखता है।
सबक के बारे में पता चला है कि कैसे अनुबंध परीक्षण आपको अपने एकीकरण परीक्षण को बाईं ओर स्थानांतरित करने में मदद कर सकता है। इसके अलावा, हमने देखा कि एकीकरण मुद्दों से संबंधित प्रतिक्रिया समय को कम करके यह आपके संगठन की लागत को कैसे कम कर सकता है।
अनुबंध परीक्षण न केवल तकनीकी परीक्षण के लिए एक उपकरण है, यह एक इकाई के रूप में परिवर्तन संचार और परीक्षण को प्रोत्साहित करके विकास टीमों के सहयोग को लागू करता है। कुल मिलाकर, यह किसी के लिए एक निरंतरता होना चाहिए जो निरंतर तैनाती की ओर देख रहा है।
अगले ट्यूटोरियल
अनुशंसित पाठ
- जावास्क्रिप्ट में एक उपभोक्ता संधि परीक्षण कैसे लिखें
- पैक्ट कॉन्ट्रैक्ट के साथ पैक्ट कॉन्ट्रैक्ट और कंटिन्युअस डिप्लॉयमेंट को वेरिफाई करें
- पैक्ट ब्रोकर के लिए संधि अनुबंध कैसे प्रकाशित करें
- सतत एकीकरण प्रक्रिया: सॉफ्टवेयर की गुणवत्ता में सुधार और जोखिम को कैसे कम करें
- यूनिट परीक्षण, एकीकरण परीक्षण और कार्यात्मक परीक्षण के बीच अंतर
- एकीकरण परीक्षण क्या है (एकीकरण परीक्षण उदाहरण के साथ ट्यूटोरियल)
- एकीकरण परीक्षण लिखने के लिए शीर्ष 10 एकीकरण परीक्षण उपकरण
- DevOps में निरंतर तैनाती