एक पूरी तरह से पृथक एंड-टू-एंड पर्यावरण की स्थापना

स्थिर एंड-टू-एंड (E2E) परीक्षणों के लिए, हमें एक ऐसे वातावरण की आवश्यकता है जो यथासंभव बाहर से अलग-थलग हो।

चंचलता कम करें

परतदार परीक्षण वे परीक्षण होते हैं जो आपके कोड से असंबंधित कारणों से विफल हो जाते हैं। वे एप्लिकेशन की शुद्धता के लिए एक विश्वसनीय जांच के रूप में E2E का उपयोग करना कठिन बनाते हैं। अत्यधिक मामलों में, परतदार परीक्षण आपकी टीम को E2E परिणामों की उपेक्षा करना सिखाएगा। यह गुणवत्ता नियंत्रण (क्यूए) को स्वचालित करने के प्रयास को खत्म कर सकता है।

यहां प्रस्तुत दृष्टिकोण आपके टेस्ट रन में संभावित मुद्दों के दो बड़े स्रोतों को संबोधित करता है:

• विभिन्न परीक्षण नौकरियों द्वारा साझा किए गए बैकएंड द्वारा संग्रहीत राज्य, और

• बाहरी सेवाएं जिन पर आपका कोई नियंत्रण नहीं है।

इस दृष्टिकोण से अप्रभावित चंचलता के अन्य स्रोत हैं:

• सही समस्या उस एप्लिकेशन में है जो बेतरतीब ढंग से दिखाई देती है, या

• एप्लिकेशन में समस्याएँ उस अप्राकृतिक गति के कारण होती हैं जिस पर E2E इसके साथ इंटरैक्ट करता है।

विकल्प

इससे पहले कि मेरी टीम और मैंने एक समर्पित बैकएंड कंटेनर के खिलाफ अपने परीक्षण चलाए, हमने अपने गैर-उत्पादन सर्वरों में से एक का उपयोग किया। यह दृष्टिकोण हमारे E2E समाधान के प्रयोग चरण में ठीक था।

जब कुछ ही परीक्षण होते थे, तब भी हम निर्णय लेने के लिए परीक्षण के परिणामों का उपयोग नहीं कर सकते थे।

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

• भले ही हमने परीक्षण के अंदर डेटा परिवर्तनों को पूर्ववत करने का प्रयास किया, कुछ परीक्षण विफलताओं के कारण अप्रत्याशित परिवर्तन हो रहे थे।

• समानांतर नौकरियां टकरा रही थीं। अलग-अलग परीक्षण नौकरियां एक ही स्थिति को बदल रही थीं, जिसके कारण अक्सर नौकरियों में से एक विफल हो जाती थी।

डॉकराइज़ सब कुछ

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

डॉकर कंटेनर चलाने के लिए एक एप्लिकेशन द्वारा आवश्यक सभी चीजों के साथ एक निहित वातावरण बनाने के लिए एक आदर्श उपकरण है:

• सही ऑपरेटिंग सिस्टम (या, बल्कि, सही लिनक्स वितरण),

• सिस्टम निर्भरता, जैसे छवि हेरफेर पुस्तकालय, आदि, और

• भाषा दुभाषियों (पायथन, नोड, आदि) या डेटाबेस सर्वर का सही संस्करण।

डेटाबेस

अपने परीक्षण के लिए, आप एक समर्पित डेटाबेस कंटेनर तैयार कर सकते हैं जो अनुमानित परीक्षण डेटा के साथ आता है। इस तरह, आप प्रत्येक E2E निष्पादन में सटीक रूप से शुरुआती बिंदु को पुन: पेश करने में सक्षम होंगे—जिससे आपके परीक्षण और अधिक स्थिर हो जाएंगे।

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

बैकएंड

यदि आप अपने बैकएंड को तैनात करने के लिए पहले से ही डॉकर का उपयोग कर चुके हैं, तो अपने E2E को चलाने के लिए उसी छवि का पुन: उपयोग करना बहुत आसान होगा। मेरी टीम में, हम एक बैकएंड को कंटेनर के रूप में तैनात करते हैं, और हम पर्यावरण चर के रूप में डेटाबेस URL और क्रेडेंशियल्स प्रदान करते हैं।

उसी कंटेनर संस्करण को उत्पादन में तैनात किया जा सकता है या परीक्षण चलाने के लिए निरंतर एकीकरण (CI) में उपयोग किया जा सकता है - प्रत्येक वातावरण DB से जुड़ने के लिए सही मान प्रदान करता है।

फ़्रंट एंड

आपकी परिनियोजन रणनीति के आधार पर, आप निम्न में से कोई एक कार्य कर सकते हैं:

1. आपके द्वारा निर्मित कंटेनरों का उपयोग फ्रंटएंड बिल्ड के एक भाग के रूप में करें।

   
   

2. संकलित फ़ाइलें प्राप्त करें और सुनिश्चित करें कि वे परीक्षणों के लिए HTTP के माध्यम से उपलब्ध हैं।

हमारे मामले में, हम विकल्प 2 का उपयोग करते हैं: हम एप्लिकेशन को स्थिर फ़ाइलों के रूप में परिनियोजित करते हैं, इसलिए हमने E2E जॉब रन के दौरान निर्मित फ़ाइलों की सेवा के लिए एक समर्पित कंटेनर बनाया है।

GitLab में नौकरी सेवाएँ

हम अपने CI को चलाने के लिए GitLab को एक प्लेटफॉर्म के रूप में उपयोग करते हैं। GitLab में प्रत्येक कार्य आपकी पसंद की छवि के साथ एक कंटेनर के अंदर चलाया जाता है। मुख्य कंटेनर के अलावा, आप सेवाओं को परिभाषित कर सकते हैं: आपके परीक्षणों के साथ चलने वाले अतिरिक्त कंटेनर। कॉन्फ़िगरेशन उतना आसान है जितना:

 <job-name>: services: - name: <image> alias: <container-url>

उपलब्ध विकल्प डॉकर कंपोज़ के समान हैं, लेकिन वे अधिक सीमित हैं।

यदि आप टेस्ट रन के दौरान सेवाओं को एक-दूसरे तक पहुंचने की अनुमति देना चाहते हैं, तो GitLab कॉन्फ़िगरेशन में एक "गोचा" चर FF_NETWORK_PER_BUILD को 1 पर सेट करना है।

इन-जॉब आइसोलेशन के लिए तदर्थ डेटा पर विचार करें

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

इस समस्या को हल करने के लिए, हमने अपने परीक्षणों को प्राथमिक रूप से उन यादृच्छिक डेटा पर निर्भर करने के लिए अपग्रेड किया है जिन्हें हम परीक्षणों के before अनुभाग के अंदर इंजेक्ट करते हैं। इसने परीक्षणों को अन्य धागों में होने वाले अन्य परिवर्तनों से अप्रभावित चलने की अनुमति दी।

यह तरीका पहली बार में थोड़ा मुश्किल हो सकता है, लेकिन यह आपकी परिस्थितियों के आधार पर समझ में आ सकता है।

हर टेस्ट के बाद सफाई करें

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

यह अब महत्वपूर्ण नहीं है, लेकिन यह अभी भी निम्नलिखित मामलों में परीक्षण के विकास के दौरान मदद कर सकता है:

• जब आप केवल एक परीक्षण चलाते हैं—तो जब आप फ़ाइल में सभी परीक्षण चलाते हैं तो परीक्षण का सामना करने की स्थिति अलग नहीं होती है।

• जब आप एक ही परीक्षण को स्थानीय रूप से बार-बार फिर से चलाते हैं—तो डेटाबेस पहले के रन से प्रभावित नहीं होता है

नकली बाहरी सेवा

ऐसे मामले हैं जब सेवाओं को एक कंटेनर में ले जाना कोई विकल्प नहीं है। उदाहरण के लिए:

• यदि ऐसे बाहरी सर्वर हैं जिनका उपयोग एप्लिकेशन सीधे या कुछ बैकएंड प्रॉक्सी के माध्यम से करता है, या

• आपके पास ऐसे सर्वर हैं जिन्हें तकनीकी समस्याओं के कारण कंटेनर के अंदर चलाना संभव नहीं है।

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

मॉक के साथ, आपके परीक्षण उन मामलों को नहीं पकड़ेंगे जब उन सेवाओं में परिवर्तन आपके आवेदन को प्रभावित करते हैं।

सीखते रहो

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