निरंतर एकीकरण के लिए डॉकर में माइक्रोसर्विसेज का स्वचालित परीक्षण

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

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

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

इस दृष्टिकोण का स्वचालन कई समस्याएं प्रस्तुत करता है, जिनका समाधान नीचे वर्णित किया जाएगा:

• एक ही डॉकर होस्ट में समानांतर कार्यों का टकराव;
• परीक्षण पुनरावृत्तियों के दौरान डेटाबेस में पहचानकर्ता संघर्ष;
• माइक्रोसर्विसेज के तैयार होने की प्रतीक्षा करना;
• लॉग को बाहरी सिस्टम में मर्ज करना और आउटपुट करना;
• आउटगोइंग HTTP अनुरोधों का परीक्षण;
• वेब सॉकेट परीक्षण (सिग्नलआर का उपयोग करके);
• OAuth प्रमाणीकरण और प्राधिकरण का परीक्षण।

यह लेख पर आधारित है मेरा भाषण SECR 2019 में। तो उन लोगों के लिए जो पढ़ने में बहुत आलसी हैं, यहां भाषण की रिकॉर्डिंग है.

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

एक ही स्क्रिप्ट स्वयं डेवलपर्स द्वारा अपने विंडोज डेस्कटॉप पर और लिनक्स के तहत Gitlab CI सर्वर द्वारा चलाई जाती है।

उचित ठहराने के लिए, नए परीक्षणों को शुरू करने के लिए डेवलपर के कंप्यूटर पर या सर्वर पर जहां परीक्षण कमिट पर चलाए जाते हैं, अतिरिक्त टूल की स्थापना की आवश्यकता नहीं होनी चाहिए। डॉकर इस समस्या को हल करता है।

निम्नलिखित कारणों से परीक्षण स्थानीय सर्वर पर चलना चाहिए:

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

इसके अलावा, स्टैंड का उपयोग करना अवांछनीय है क्योंकि:

• एक स्टैंड को न केवल उस पर चल रहे खराब कोड से तोड़ा जा सकता है, बल्कि उस डेटा से भी तोड़ा जा सकता है जिसे सही कोड प्रोसेस नहीं कर सकता है;
• इससे कोई फर्क नहीं पड़ता कि हम परीक्षण के दौरान परीक्षण द्वारा किए गए सभी परिवर्तनों को वापस लाने का कितना प्रयास करते हैं, कुछ गलत हो सकता है (अन्यथा, परीक्षण क्यों?)।

परियोजना और प्रक्रिया संगठन के बारे में

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

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

परियोजना वास्तुकला

एप्लिकेशन में दस से अधिक सेवाएँ शामिल हैं। उनमें से कुछ .NET कोर में और कुछ NodeJs में लिखे गए हैं। अमेज़ॅन इलास्टिक कंटेनर सेवा में प्रत्येक सेवा एक डॉकर कंटेनर में चलती है। प्रत्येक का अपना पोस्टग्रेज डेटाबेस है, और कुछ के पास रेडिस भी है। कोई सामान्य डेटाबेस नहीं हैं. यदि कई सेवाओं को समान डेटा की आवश्यकता होती है, तो यह डेटा, जब यह बदलता है, तो एसएनएस (सिंपल नोटिफिकेशन सर्विस) और एसक्यूएस (अमेज़ॅन सिंपल क्यू सर्विस) के माध्यम से इनमें से प्रत्येक सेवा को प्रेषित किया जाता है, और सेवाएं इसे अपने अलग डेटाबेस में सहेजती हैं।

एसक्यूएस और एसएनएस

एसक्यूएस आपको संदेशों को एक कतार में रखने और HTTPS प्रोटोकॉल का उपयोग करके कतार से संदेशों को पढ़ने की अनुमति देता है।

यदि कई सेवाएँ एक कतार को पढ़ती हैं, तो प्रत्येक संदेश उनमें से केवल एक को ही आता है। यह तब उपयोगी होता है जब एक ही सेवा के कई उदाहरणों को उनके बीच लोड वितरित करने के लिए चलाया जाता है।

यदि आप चाहते हैं कि प्रत्येक संदेश एकाधिक सेवाओं तक पहुंचाया जाए, तो प्रत्येक प्राप्तकर्ता की अपनी कतार होनी चाहिए, और संदेशों को एकाधिक कतारों में डुप्लिकेट करने के लिए एसएनएस की आवश्यकता होती है।

एसएनएस में आप एक विषय बनाते हैं और उसकी सदस्यता लेते हैं, उदाहरण के लिए, एक एसक्यूएस कतार। आप विषय पर संदेश भेज सकते हैं. इस मामले में, संदेश इस विषय की सदस्यता वाली प्रत्येक कतार को भेजा जाता है। एसएनएस के पास संदेशों को पढ़ने की कोई विधि नहीं है। यदि डिबगिंग या परीक्षण के दौरान आपको यह पता लगाना है कि एसएनएस को क्या भेजा गया है, तो आप एक एसक्यूएस कतार बना सकते हैं, इसे वांछित विषय की सदस्यता ले सकते हैं और कतार को पढ़ सकते हैं।

एपीआई गेटवे

अधिकांश सेवाएँ सीधे इंटरनेट से उपलब्ध नहीं हैं। एक्सेस एपीआई गेटवे के माध्यम से होता है, जो एक्सेस अधिकारों की जांच करता है। यह हमारी सेवा भी है और इसके लिए परीक्षण भी होते हैं.

वास्तविक समय सूचनाएं

एप्लिकेशन उपयोग करता है Signalrउपयोगकर्ता को वास्तविक समय सूचनाएं दिखाने के लिए। इसे अधिसूचना सेवा में लागू किया गया है। यह सीधे इंटरनेट से पहुंच योग्य है और स्वयं OAuth के साथ काम करता है, क्योंकि OAuth और अधिसूचना सेवा को एकीकृत करने की तुलना में, गेटवे में वेब सॉकेट के लिए समर्थन बनाना अव्यावहारिक साबित हुआ।

सुप्रसिद्ध परीक्षण दृष्टिकोण

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

В माइक्रोसॉफ्ट से लेख इन-मेमोरी डेटाबेस का उपयोग करने और नकली वस्तुओं को लागू करने का प्रस्ताव है।

इन-मेमोरी डेटाबेस एंटिटी फ्रेमवर्क द्वारा समर्थित DBMS में से एक है। इसे विशेष रूप से परीक्षण के लिए बनाया गया था। ऐसे डेटाबेस में डेटा केवल तब तक संग्रहीत किया जाता है जब तक कि इसका उपयोग करने वाली प्रक्रिया समाप्त न हो जाए। इसमें तालिकाएँ बनाने की आवश्यकता नहीं है और यह डेटा अखंडता की जाँच नहीं करता है।

मॉक ऑब्जेक्ट उस वर्ग का मॉडल बनाते हैं जिसे वे केवल उस सीमा तक प्रतिस्थापित कर रहे हैं, जब तक कि परीक्षण डेवलपर समझ जाता है कि यह कैसे काम करता है।

जब आप कोई परीक्षण चलाते हैं तो पोस्टग्रेज़ को स्वचालित रूप से प्रारंभ करने और माइग्रेशन करने के लिए कैसे प्राप्त करें, यह Microsoft आलेख में निर्दिष्ट नहीं है। मेरा समाधान ऐसा करता है और इसके अलावा, विशेष रूप से माइक्रोसर्विस में परीक्षणों के लिए कोई कोड नहीं जोड़ता है।

चलिए समाधान की ओर बढ़ते हैं

विकास प्रक्रिया के दौरान, यह स्पष्ट हो गया कि इकाई परीक्षण समय पर सभी समस्याओं का पता लगाने के लिए पर्याप्त नहीं थे, इसलिए इस मुद्दे को एक अलग कोण से देखने का निर्णय लिया गया।

एक परीक्षण वातावरण स्थापित करना

पहला कार्य एक परीक्षण वातावरण तैनात करना है। माइक्रोसर्विस चलाने के लिए आवश्यक कदम:

• स्थानीय परिवेश के लिए परीक्षण के तहत सेवा को कॉन्फ़िगर करें, पर्यावरण चर में डेटाबेस और AWS से कनेक्ट करने के लिए विवरण निर्दिष्ट करें;
• पोस्टग्रेज प्रारंभ करें और लिक्विबेस चलाकर माइग्रेशन करें।
  रिलेशनल डीबीएमएस में, डेटाबेस में डेटा लिखने से पहले, आपको एक डेटा स्कीमा, दूसरे शब्दों में, टेबल बनाने की आवश्यकता होती है। किसी एप्लिकेशन को अपडेट करते समय, तालिकाओं को नए संस्करण द्वारा उपयोग किए गए फॉर्म में लाया जाना चाहिए, और, अधिमानतः, डेटा खोए बिना। इसे माइग्रेशन कहा जाता है. प्रारंभ में खाली डेटाबेस में तालिकाएँ बनाना माइग्रेशन का एक विशेष मामला है। माइग्रेशन को एप्लिकेशन में ही बनाया जा सकता है। .NET और NodeJS दोनों में माइग्रेशन फ्रेमवर्क हैं। हमारे मामले में, सुरक्षा कारणों से, माइक्रोसर्विसेज डेटा स्कीमा को बदलने के अधिकार से वंचित हैं, और माइग्रेशन लिक्विबेस का उपयोग करके किया जाता है।
• अमेज़ॅन लोकलस्टैक लॉन्च करें। यह घर पर चलाने के लिए AWS सेवाओं का कार्यान्वयन है। डॉकर हब पर लोकलस्टैक के लिए एक तैयार छवि है।
• लोकलस्टैक में आवश्यक इकाइयाँ बनाने के लिए स्क्रिप्ट चलाएँ। शेल स्क्रिप्ट AWS CLI का उपयोग करती हैं।

प्रोजेक्ट पर परीक्षण के लिए उपयोग किया जाता है पोस्टमैन. यह पहले से मौजूद था, लेकिन इसे मैन्युअल रूप से लॉन्च किया गया था और स्टैंड पर पहले से ही तैनात एक एप्लिकेशन का परीक्षण किया गया था। यह टूल आपको मनमाना HTTP(S) अनुरोध करने और यह जांचने की अनुमति देता है कि प्रतिक्रियाएँ अपेक्षा के अनुरूप हैं या नहीं। क्वेरीज़ को एक संग्रह में संयोजित किया जाता है, और संपूर्ण संग्रह चलाया जा सकता है।

स्वचालित परीक्षण कैसे काम करता है?

परीक्षण के दौरान, सब कुछ डॉकर में काम करता है: परीक्षण के तहत सेवा, पोस्टग्रेज, माइग्रेशन टूल और पोस्टमैन, या बल्कि इसका कंसोल संस्करण - न्यूमैन।

डॉकर कई समस्याओं का समाधान करता है:

• मेजबान विन्यास से स्वतंत्रता;
• निर्भरताएँ स्थापित करना: डॉकर डॉकर हब से छवियाँ डाउनलोड करता है;
• सिस्टम को उसकी मूल स्थिति में लौटाना: बस कंटेनरों को हटाना।

docker-रचना कंटेनरों को इंटरनेट से अलग एक वर्चुअल नेटवर्क में एकजुट करता है, जिसमें कंटेनर डोमेन नाम से एक-दूसरे को ढूंढते हैं।

परीक्षण को शेल स्क्रिप्ट द्वारा नियंत्रित किया जाता है। विंडोज़ पर परीक्षण चलाने के लिए हम git-bash का उपयोग करते हैं। इस प्रकार, विंडोज़ और लिनक्स दोनों के लिए एक स्क्रिप्ट पर्याप्त है। प्रोजेक्ट पर सभी डेवलपर्स द्वारा Git और Docker इंस्टॉल किए गए हैं। विंडोज़ पर गिट इंस्टॉल करते समय, गिट-बैश इंस्टॉल किया जाता है, इसलिए हर किसी के पास वह भी होता है।

स्क्रिप्ट निम्नलिखित चरण निष्पादित करती है:

• डोकर छवियों का निर्माण

  docker-compose build

• डेटाबेस और लोकलस्टैक लॉन्च करना

  docker-compose up -d <контейнер>

• डेटाबेस माइग्रेशन और लोकलस्टैक की तैयारी

  docker-compose run <контейнер>

• परीक्षणाधीन सेवा प्रारंभ करना

  docker-compose up -d <сервис>

• परीक्षण चलाना (न्यूमैन)
• सभी कंटेनरों को रोका जा रहा है

  docker-compose down

• स्लैक में परिणाम पोस्ट करना
  हमारे पास एक चैट है जहां हरे चेकमार्क या लाल क्रॉस वाले संदेश और लॉग का लिंक जाता है।

निम्नलिखित डॉकर छवियां इन चरणों में शामिल हैं:

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

का प्रयोग संस्करणों, आपको केवल कंटेनर में फ़ाइलें जोड़ने के लिए डॉकर छवि बनाने की आवश्यकता नहीं है। हालाँकि, वॉल्यूम हमारे पर्यावरण के लिए उपयुक्त नहीं हैं क्योंकि Gitlab CI कार्य स्वयं कंटेनरों में चलते हैं। आप ऐसे कंटेनर से डॉकर को नियंत्रित कर सकते हैं, लेकिन वॉल्यूम केवल होस्ट सिस्टम से फ़ोल्डर्स को माउंट करते हैं, किसी अन्य कंटेनर से नहीं।

आपके सामने समस्याएँ आ सकती हैं

तत्परता की प्रतीक्षा में

जब किसी सेवा वाला कंटेनर चल रहा है, तो इसका मतलब यह नहीं है कि वह कनेक्शन स्वीकार करने के लिए तैयार है। आपको कनेक्शन जारी रहने तक प्रतीक्षा करनी होगी.

इस समस्या को कभी-कभी स्क्रिप्ट का उपयोग करके हल किया जाता है इसके लिए प्रतीक्षा करें.श, जो टीसीपी कनेक्शन स्थापित करने के अवसर की प्रतीक्षा करता है। हालाँकि, लोकलस्टैक 502 ख़राब गेटवे त्रुटि उत्पन्न कर सकता है। इसके अलावा, इसमें कई सेवाएँ शामिल हैं, और यदि उनमें से एक तैयार है, तो यह दूसरों के बारे में कुछ नहीं कहता है।

समाधान: लोकलस्टैक प्रोविजनिंग स्क्रिप्ट जो एसक्यूएस और एसएनएस दोनों से 200 प्रतिक्रिया की प्रतीक्षा करती है।

समानांतर कार्य संघर्ष

एक ही डॉकर होस्ट पर कई परीक्षण एक साथ चल सकते हैं, इसलिए कंटेनर और नेटवर्क नाम अद्वितीय होने चाहिए। इसके अलावा, एक ही सेवा की विभिन्न शाखाओं के परीक्षण भी एक साथ चल सकते हैं, इसलिए प्रत्येक कंपोज़ फ़ाइल में उनके नाम लिखना पर्याप्त नहीं है।

समाधान: स्क्रिप्ट COMPOSE_PROJECT_NAME वैरिएबल को एक अद्वितीय मान पर सेट करती है।

विंडोज़ की विशेषताएं

विंडोज़ पर डॉकर का उपयोग करते समय मैं कई चीजें इंगित करना चाहता हूं, क्योंकि ये अनुभव यह समझने के लिए महत्वपूर्ण हैं कि त्रुटियां क्यों होती हैं।

1. किसी कंटेनर में शेल स्क्रिप्ट में लिनक्स लाइन अंत होना चाहिए।
   शेल सीआर प्रतीक एक वाक्यविन्यास त्रुटि है। त्रुटि संदेश से यह बताना कठिन है कि मामला यही है। विंडोज़ पर ऐसी स्क्रिप्ट संपादित करते समय, आपको एक उचित टेक्स्ट एडिटर की आवश्यकता होती है। इसके अलावा, संस्करण नियंत्रण प्रणाली को ठीक से कॉन्फ़िगर किया जाना चाहिए।

इस प्रकार git कॉन्फ़िगर किया गया है:

git config core.autocrlf input

1. Git-bash मानक Linux फ़ोल्डरों का अनुकरण करता है और, exe फ़ाइल (docker.exe सहित) को कॉल करते समय, पूर्ण Linux पथों को Windows पथों से बदल देता है। हालाँकि, इसका उन पथों के लिए कोई मतलब नहीं है जो स्थानीय मशीन पर नहीं हैं (या किसी कंटेनर में पथ)। इस व्यवहार को अक्षम नहीं किया जा सकता.

समाधान: पथ की शुरुआत में एक अतिरिक्त स्लैश जोड़ें: /bin के बजाय //bin। लिनक्स ऐसे पथों को समझता है; इसके लिए, कई स्लैश एक जैसे होते हैं। लेकिन git-bash ऐसे रास्तों को नहीं पहचानता और उन्हें परिवर्तित करने का प्रयास नहीं करता।

लॉग आउटपुट

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

मूल समाधान करना था डॉक-अप लिखें कोई झंडा नहीं -d, लेकिन शेल क्षमताओं का उपयोग करके, इस प्रक्रिया को पृष्ठभूमि पर भेजें:

docker-compose up <service> &

यह तब तक काम करता रहा जब तक डॉकर से किसी तृतीय-पक्ष सेवा को लॉग भेजना आवश्यक नहीं हो गया। डॉक-अप लिखें कंसोल पर लॉग आउटपुट करना बंद कर दिया। हालाँकि, टीम ने काम किया डॉकर संलग्न करें.

समाधान:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

परीक्षण पुनरावृत्तियों के दौरान पहचानकर्ता संघर्ष

परीक्षण कई पुनरावृत्तियों में चलाए जाते हैं। डेटाबेस साफ़ नहीं किया गया है. डेटाबेस में रिकॉर्ड्स में अद्वितीय आईडी होती हैं। यदि हम अनुरोधों में विशिष्ट आईडी लिखते हैं, तो हमें दूसरे पुनरावृत्ति पर एक विरोध मिलेगा।

इससे बचने के लिए, या तो आईडी अद्वितीय होनी चाहिए, या परीक्षण द्वारा बनाई गई सभी वस्तुओं को हटा दिया जाना चाहिए। कुछ वस्तुओं को आवश्यकताओं के कारण हटाया नहीं जा सकता।

समाधान: पोस्टमैन स्क्रिप्ट का उपयोग करके GUID उत्पन्न करें।

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

फिर क्वेरी में प्रतीक का उपयोग करें {{myUUID}}, जिसे वेरिएबल के मान से बदल दिया जाएगा।

लोकलस्टैक के माध्यम से सहयोग

यदि परीक्षण की जा रही सेवा किसी SQS कतार को पढ़ती या लिखती है, तो इसे सत्यापित करने के लिए, परीक्षण को भी इस कतार के साथ काम करना होगा।

समाधान: पोस्टमैन से लोकलस्टैक तक अनुरोध।

AWS सेवा API प्रलेखित है, जो SDK के बिना क्वेरी करने की अनुमति देता है।

यदि कोई सेवा किसी कतार में लिखती है, तो हम उसे पढ़ते हैं और संदेश की सामग्री की जांच करते हैं।

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

यदि सेवा को कतार से एक संदेश पढ़ने की आवश्यकता है, तो पिछले परीक्षण चरण में हम इस संदेश को कतार में लिखते हैं।

परीक्षण के तहत माइक्रोसर्विस से उत्पन्न HTTP अनुरोधों का परीक्षण

कुछ सेवाएँ AWS के अलावा किसी अन्य चीज़ के साथ HTTP पर काम करती हैं, और कुछ AWS सुविधाएँ लोकलस्टैक में लागू नहीं की जाती हैं।

समाधान: इन मामलों में यह मदद कर सकता है मॉकसर्वर, जिसमें एक तैयार छवि है डॉकर हब. अपेक्षित अनुरोध और उन पर प्रतिक्रियाएँ HTTP अनुरोध द्वारा कॉन्फ़िगर की जाती हैं। एपीआई प्रलेखित है, इसलिए हम पोस्टमैन से अनुरोध करते हैं।

OAuth प्रमाणीकरण और प्राधिकरण का परीक्षण

हम OAuth और का उपयोग करते हैं JSON वेब कैम (JWT). परीक्षण के लिए एक OAuth प्रदाता की आवश्यकता होती है जिसे हम स्थानीय रूप से चला सकते हैं।

सेवा और OAuth प्रदाता के बीच सभी इंटरैक्शन दो अनुरोधों पर आते हैं: पहला, कॉन्फ़िगरेशन का अनुरोध किया जाता है /.जाने-माने/ओपनिड-कॉन्फ़िगरेशन, और फिर कॉन्फ़िगरेशन के पते पर सार्वजनिक कुंजी (JWKS) का अनुरोध किया जाता है। यह सब स्थिर सामग्री है.

समाधान: हमारा परीक्षण OAuth प्रदाता एक स्थिर सामग्री सर्वर और उस पर दो फ़ाइलें है। टोकन एक बार उत्पन्न होता है और Git के लिए प्रतिबद्ध होता है।

सिग्नलआर परीक्षण की विशेषताएं

डाकिया वेबसोकेट के साथ काम नहीं करता. सिग्नलआर का परीक्षण करने के लिए एक विशेष उपकरण बनाया गया था।

एक सिग्नलआर क्लाइंट सिर्फ एक ब्राउज़र से कहीं अधिक हो सकता है। .NET कोर के अंतर्गत इसके लिए एक क्लाइंट लाइब्रेरी है। .NET कोर में लिखा गया क्लाइंट, एक कनेक्शन स्थापित करता है, प्रमाणित होता है, और संदेशों के एक विशिष्ट अनुक्रम की प्रतीक्षा करता है। यदि कोई अप्रत्याशित संदेश प्राप्त होता है या कनेक्शन खो जाता है, तो क्लाइंट 1 के कोड के साथ बाहर निकलता है। यदि अंतिम अपेक्षित संदेश प्राप्त होता है, तो क्लाइंट 0 के कोड के साथ बाहर निकलता है।

न्यूमैन क्लाइंट के साथ एक साथ काम करता है। यह जांचने के लिए कई क्लाइंट लॉन्च किए गए हैं कि संदेश उन सभी लोगों तक पहुंचाए जाएं जिन्हें उनकी जरूरत है।

एकाधिक क्लाइंट चलाने के लिए विकल्प का उपयोग करें --पैमाना डॉकर-कंपोज़ कमांड लाइन पर।

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

समाधान: कंटेनर में क्लाइंट तंत्र का उपयोग करता है स्वास्थ्य जांचहोस्ट पर स्क्रिप्ट को उसकी स्थिति के बारे में सूचित करने के लिए। जैसे ही कनेक्शन स्थापित होता है, क्लाइंट एक विशिष्ट पथ पर एक फ़ाइल बनाता है, जैसे /healthcheck। डॉकर फ़ाइल में हेल्थचेक स्क्रिप्ट इस तरह दिखती है:

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

टीम डोकर निरीक्षण कंटेनर की सामान्य स्थिति, स्वास्थ्य स्थिति और निकास कोड दिखाता है।

न्यूमैन के पूरा होने के बाद, स्क्रिप्ट जाँचती है कि क्लाइंट के साथ सभी कंटेनर कोड 0 के साथ समाप्त हो गए हैं।

हैप्पीनेस मौजूद है

ऊपर वर्णित कठिनाइयों पर काबू पाने के बाद, हमारे पास स्थिर चलने वाले परीक्षणों का एक सेट था। परीक्षणों में, प्रत्येक सेवा डेटाबेस और अमेज़ॅन लोकलस्टैक के साथ इंटरैक्ट करते हुए एक इकाई के रूप में काम करती है।

ये परीक्षण 30+ डेवलपर्स की एक टीम को बार-बार तैनाती के साथ 10+ माइक्रोसर्विसेज की जटिल बातचीत वाले एप्लिकेशन में त्रुटियों से बचाते हैं।

स्रोत: www.habr.com