बाहरी सेवाओं के साथ परीक्षण एकीकरण

आधुनिक अनुप्रयोग शायद ही कभी अलगाव में काम करते हैं, अक्सर वे कई तृतीय-पक्ष सेवाओं के साथ एकीकृत होते हैं। इसलिए, एकीकरण या कार्यात्मक परीक्षण के ढांचे में इस एकीकरण का परीक्षण करने का मुद्दा एक तीव्र मुद्दा है। और यहां आप कई रेक पर कदम रख सकते हैं, जिसके बारे में मैं बात करने जा रहा हूं। जिनके लिए यह विषय प्रासंगिक है, मैं बिल्ली के नीचे पूछता हूं।

वास्तविक समस्या क्या है?

पहला समाधान जो दिमाग में आता है वह है वास्तविक सेवा पर सीधे परीक्षण करना। कुछ मामलों में, यह उचित हो सकता है, लेकिन अक्सर निम्नलिखित समस्याएं होती हैं:

• टेस्ट काफी धीमा हो जाता है । बाहरी प्रोटोकॉल तक पहुंच आमतौर पर सार्वजनिक प्रोटोकॉल का उपयोग करके नेटवर्क पर की जाती है, जो स्थानीय एकीकरण की तुलना में बहुत धीमी है। बाहरी सेवा आमतौर पर इतनी तेज़ नहीं होती है और अपने भार के अधीन होती है, जिसके दौरान यह और भी धीमा हो सकता है। नतीजतन, मैंने 10 मिनट से लेकर कुछ घंटों तक एकीकरण परीक्षण सूट में मंदी देखी है, और रनटाइम बहुत अस्थायी था।
• टेस्ट कम होते जा रहे हैं । जैसा कि मैंने पहले ही कहा, बाहरी सेवाएं तनाव के अधीन हैं, कभी-कभी अपडेट के कारण अनुपलब्ध, "क्रैश" जब सेवा डेवलपर्स गलत तरीके से अपडेट करते हैं, और नेटवर्क त्रुटियां भी संभव हैं। यह सब आपके परीक्षण सूट और इसकी स्थिरता को बहुत प्रभावित करता है। परीक्षण "अप्रत्याशित रूप से" गिर जाते हैं, इस समस्या का अध्ययन करने में लंबा समय लगता है, और टीम के सदस्यों ने एक पूरे के रूप में परीक्षणों को अविश्वास करना शुरू कर दिया। नतीजतन, परीक्षण की बहुत उपयोगिता को प्रश्न में कहा जा सकता है।
• आपके पास बाहरी सेवा (त्रुटियों, विशिष्ट डेटा, आदि) से कुछ उत्तर प्राप्त करने का अवसर नहीं है , जो आपके कोड के कवरेज को परीक्षणों से प्रभावित कर सकता है, जिसका अर्थ है एकीकरण परीक्षणों द्वारा प्रतिगमन परीक्षण की विश्वसनीयता। आखिरकार, न केवल सकारात्मक, बल्कि नकारात्मक परिदृश्यों को भी कवर करना आवश्यक है।
• एक वास्तविक सेवा में हमेशा एक परीक्षण इंटरफ़ेस नहीं होता है और आपको पूरी तरह से वास्तविक का उपयोग करना होता है। और यह हमेशा मुफ़्त नहीं होता है और आपके कोड की कोई भी त्रुटि बाहरी डेटा पर वास्तविक डेटा को खतरे में डालती है । इस समस्या के कारण, आप बहुत महत्वपूर्ण डेटा को आसानी से हटा सकते हैं या किसी वास्तविक एप्लिकेशन से पहुंच को ब्लॉक कर सकते हैं। और यह उल्लेख नहीं है कि बाहरी सेवा के "अप्रत्याशित" उपयोग पर बहुत पैसा खर्च किया जा सकता है।

वर्णित समस्याएं आपको वैकल्पिक समाधान की तलाश करती हैं और वे मौजूद हैं।

स्टब्स परीक्षण की दुनिया पर राज करते हैं!

स्टब्स के लिए विभिन्न प्रकार के विकल्प आपकी सहायता के लिए आ सकते हैं (मैंने मॉक ऑब्जेक्ट का बेहतर अनुवाद नहीं पाया है)। स्टब्स के लिए कई विकल्प हैं: मॉक, स्टब, डमी, जासूस, नकली। उन्हें जानना और अलग करना आवश्यक है, इसलिए यह बारीकियों को पढ़ने और समझने लायक है, लेकिन इस पर चर्चा नहीं की जाएगी। हमें केवल एक प्रकार के स्टब की आवश्यकता है जो बाहरी सेवाओं के साथ काम करने के लिए सबसे उपयुक्त है - नकली कार्यान्वयन ।

नकली कार्यान्वयन इस सेवा का एक सरलीकृत संस्करण है जो पूरी तरह से, स्थानीय रूप से काम करता है, डेटा और सेटिंग्स तक पूरी पहुँच देता है, और प्रत्येक परीक्षण में किसी अतिरिक्त कार्य की भी आवश्यकता नहीं होती है। इस प्रकार, हम नकली कार्यान्वयन के लिए परीक्षणों में वास्तविक सेवा को पारदर्शी रूप से बदल सकते हैं और सभी समस्याओं को हल कर सकते हैं। क्या वह सरल है? सच में नहीं!

सबसे पहले, हमें सेवा के इस सरलीकृत संस्करण को लागू करने की आवश्यकता होगी, जो डेवलपर्स के समय और प्रयासों को ले जाएगा। आप भाग्यशाली हैं यदि आपकी बाहरी सेवा स्थानीय परीक्षण के लिए नकली कार्यान्वयन प्रदान करती है। फिर आप बस पुस्तकालय डाउनलोड करें, कॉन्फ़िगर करें, लॉन्च करें और अपने स्वास्थ्य का उपयोग करें। कुछ सेवाएं आपको परीक्षण के लिए एक बाहरी सेवा के विशेष संस्करण तक पहुंचने की अनुमति देती हैं, जो पहले भाग में सूचीबद्ध समस्याओं के अधीन नहीं है। लेकिन ऐसी सेवाएं कम हैं। लगभग हमेशा, आपको खुद को एक नकली कार्यान्वयन लिखना होगा।

दूसरे, आपको यह सुनिश्चित करना होगा कि आपका नकली कार्यान्वयन वास्तविक सेवा के समान व्यवहार करे। यह सबसे लगातार रेक में से एक है जिस पर वर्णित दृष्टिकोण के प्रस्तावक हमला करते हैं। आप आज एक नकली कार्यान्वयन करते हैं, और एक हफ्ते के बाद वास्तविक सेवा अलग तरह से व्यवहार करना शुरू कर देती है। आपके परीक्षण अभी भी गुजरते हैं और आप चुपचाप रहते हैं जब तक आप अपने कोड को लाइव सर्वर पर तैनात नहीं करते हैं। और वहां आपको एक अप्रिय आश्चर्य मिलेगा!

इस समस्या को ठीक करना बहुत आसान है, लेकिन यह थोड़ा और प्रयास करेगा। आपको परीक्षण का एक और सेट लिखने की ज़रूरत है, अब एक वास्तविक सेवा के लिए, जिसका उद्देश्य आपके आवेदन और एक तृतीय-पक्ष सेवा के बीच प्रोटोकॉल की विश्वसनीयता को नियंत्रित करना और बनाए रखना है। यह बाहरी सेवा के लिए किसी प्रकार का धुआँ परीक्षण है , जो आपकी बाहरी सेवा की स्थिरता के आधार पर, घंटे, दिन या सप्ताह में एक बार चलाया जा सकता है। तब आप वास्तव में एक बाहरी सेवा के साथ एकीकरण को नियंत्रित और परीक्षण करते हैं और इसे बदलते समय आश्चर्य से बचते हैं।

मैं इस तरह के बदलाव के लिए तैयार नहीं हूं!

वर्णित समाधान हर किसी के लिए उपयुक्त नहीं है (सिद्धांत रूप में, किसी भी अन्य की तरह)। इसलिए, मैं कुछ सुझाव दूंगा जिनकी मदद से आप इस लेख के पहले भाग में समस्याओं को सुलझा सकते हैं।

• उन परीक्षणों में विभाजित करें जहां आपको बाहरी सेवाओं के साथ एकीकरण की आवश्यकता होती है, और जहां आपके उत्पाद की केवल आंतरिक कार्यक्षमता महत्वपूर्ण है। मैं आपको कुछ सरल उदाहरण देता हूं। यदि आप पंजीकरण का परीक्षण कर रहे हैं, तो विज्ञापन प्रदर्शित करने की प्रणाली, ट्विटर से नवीनतम पोस्ट को खींचना, आदि शायद आपके लिए इतना महत्वपूर्ण नहीं है। इसलिए, बाहरी सेवाओं को अक्षम किया जा सकता है। प्रत्येक आवेदन में, यह अपने तरीके से किया जा सकता है। उदाहरण के लिए, एक वेब एप्लिकेशन में एक नियंत्रित प्रॉक्सी का उपयोग करना बहुत सरल है, जो किसी भी समय बाहरी सेवाओं तक पहुंच को अवरुद्ध कर सकता है। इस तरह का एक सरल उपाय आपको अपने परीक्षणों में बहुत तेजी लाने की अनुमति देगा।
• बाहरी सेवाओं से डेटा प्राप्त करने के लिए कस्टम कैशिंग का सक्रिय रूप से उपयोग करें । आमतौर पर, एकीकरण या कार्यात्मक परीक्षण के दौरान, आप बार-बार एप्लिकेशन के समान भागों से गुजरते हैं, और हमेशा अद्यतन डेटा की आवश्यकता नहीं होती है। इसलिए, आप पिछले कॉल के परिणामों को कैशिंग करके बाहरी सेवाओं पर कॉल को बचा सकते हैं। इस प्रकार, आप अभी भी वास्तविक डेटा की प्राप्ति का परीक्षण कर रहे हैं, लेकिन बहुत अधिक आशा के साथ।
• अपनी सेवा के लिए एक खुला स्रोत नकली समाधान के लिए सुनिश्चित करें। आमतौर पर लोकप्रिय सेवाओं के लिए, यह मौजूद है, क्योंकि बहुत सारे लोग एक समान परीक्षण कार्य का सामना करते हैं और उनमें से सभी आपके जैसे आलसी नहीं हैं। उदाहरण के लिए, अमेज़ॅन एस 3 सेवा के साथ काम करने के लिए एक अद्भुत नकली-एस 3 परियोजना है। यह एक ही एपीआई को लागू करता है, जिससे आप मुफ्त, सुरक्षित और स्थानीय रूप से एकीकरण का परीक्षण कर सकते हैं। आपको बस अपने एप्लिकेशन में सेवा तक पहुंच को कॉन्फ़िगर करने की क्षमता है।
• अपने सेवा प्रदाता से पूछें कि क्या उसमें परीक्षण को स्थानीय बनाने की क्षमता है। शायद आप बस ऐसे समाधानों के अस्तित्व के बारे में नहीं जानते हैं या इसे बनाने के लिए प्रदाता को धक्का देंगे। वे मांग को हरा नहीं करते हैं, जैसा कि वे कहते हैं।

यहां तक ​​कि उपायों के इस सेट से उनके परीक्षण में काफी सुधार होगा।

निष्कर्ष

सामान्य तौर पर, सबसे महत्वपूर्ण बात वर्णित समस्याओं को समझना और उन्हें हल करने की इच्छा है। फिर आप कई वैकल्पिक समाधानों और दृष्टिकोणों के साथ आ सकते हैं जो आपके विशिष्ट मामले के लिए लेख में दिए गए से भी बेहतर काम करेंगे। और फिर आपके परीक्षण फिर से तेज, विश्वसनीय और आपकी टीम के लिए और भी अधिक उपयोगी होंगे।