🛰️ 🥒 ⛸️ सैकड़ों क्लाइंट संस्करणों के लिए मोनोलिथ: हम परीक्षण कैसे लिखते हैं और समर्थन करते हैं 👩🏽‍🏭 🧔🏿 👋🏾

सभी को नमस्कार!

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

हम किस बारे में बात करेंगे? सबसे पहले, मैं संक्षेप में हमारी विकास प्रक्रिया के बारे में बात करूँगा और यह हमारी परीक्षणों की आवश्यकता और इन परीक्षणों को लिखने की इच्छा को कैसे प्रभावित करता है। फिर हम परीक्षण स्वचालन के पिरामिड के ऊपर और नीचे जाएंगे, हमारे द्वारा उपयोग किए जाने वाले परीक्षणों के प्रकारों पर चर्चा करें, उनमें से प्रत्येक के अंदर उपकरणों के बारे में बात करें और हम उनकी मदद से क्या समस्याएं हल करें। अंत में, विचार करें कि इस सभी सामान को कैसे बनाए रखा जाए और कैसे चलाया जाए।

हमारी विकास प्रक्रिया

हमने अपनी विकास प्रक्रिया का सचित्र वर्णन किया है:

एक गोल्फर एक बैकएंड डेवलपर है। कुछ बिंदु पर, एक विकास कार्य उस पर आता है, आमतौर पर दो दस्तावेजों के रूप में: व्यापार की ओर से आवश्यकताओं और एक तकनीकी दस्तावेज जो बैकएंड और क्लाइंट (मोबाइल एप्लिकेशन और साइट) के बीच बातचीत के हमारे प्रोटोकॉल में परिवर्तन का वर्णन करता है।

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

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

यह स्थिति काफी संभव है: छह महीने पहले, आपने कुछ सुविधा शुरू की थी, ग्राहक टीमों ने इसे लंबे समय तक लागू नहीं किया था, क्योंकि कंपनी की प्राथमिकताएं बदल गई हैं, आप पहले से ही अन्य कार्यों पर काम करने में व्यस्त हैं, आपके पास नई समय सीमाएं, प्राथमिकताएं हैं - और यहां आपके सहकर्मी आते हैं और वे कहते हैं: “क्या तुम्हें यह बात याद है कि तुम छह महीने पहले नहाए हो? वह काम नहीं कर रही है। ” और नए कार्यों में संलग्न होने के बजाय, आप आग लगा देते हैं।

इसलिए, हमारे डेवलपर्स के पास PHP प्रोग्रामर के लिए एक प्रेरणा असामान्य है - यह सुनिश्चित करने के लिए कि एकीकरण चरण के दौरान यथासंभव कम समस्याएं हैं।

आप यह सुनिश्चित करने के लिए सबसे पहले क्या करना चाहते हैं कि फीचर काम करता है?

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

और यहाँ स्वचालित परीक्षण हमारी सहायता के लिए आते हैं।

यूनिट परीक्षण

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

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

SoftMocks

इकाई परीक्षण लिखते समय डेवलपर्स को जो मुख्य कठिनाई होती है, वह अनस्टेबल कोड है, और यह आमतौर पर विरासत कोड है।

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

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

यह एक डेवलपर के लिए ऐसा दिखता है:

//mock  \Badoo\SoftMocks::redefineConstant($constantName, $newValue); //mock  : , ,  \Badoo\SoftMocks::redefineMethod( $class, $method, $method_args, $fake_code ); //mock  \Badoo\SoftMocks::redefineFunction( $function, $function_args, $fake_code );

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

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

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

इन नियमों का अनुपालन सावधानीपूर्वक कोड समीक्षा चरण में किया जाता है।

उत्परिवर्तन परीक्षण

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

हाल ही में, हमने पारस्परिक परीक्षण शुरू किया। यह एक पुरानी बात है, लेकिन बहुत अच्छी तरह से ज्ञात अवधारणा नहीं है। इस तरह के परीक्षण के लिए एल्गोरिथ्म काफी सरल है:

कोड और कोड कवरेज ले;
पार्सिम और कोड को बदलना शुरू करें: सच को गलत,> से> =, + से - (सामान्य रूप से, हर तरह से नुकसान);
ऐसे प्रत्येक म्यूटेशन परिवर्तन के लिए, परीक्षण सूट चलाएं जो परिवर्तित स्ट्रिंग को कवर करते हैं;
यदि परीक्षण गिरते हैं, तो वे अच्छे हैं और वास्तव में हमें कोड को तोड़ने की अनुमति नहीं देते हैं;
यदि परीक्षण पास हो गए हैं, तो सबसे अधिक संभावना है, वे कवरेज के बावजूद पर्याप्त प्रभावी नहीं हैं, और कुछ मुखर (या परीक्षण द्वारा कवर नहीं किया गया क्षेत्र) देने के लिए उन्हें अधिक बारीकी से देखने के लायक हो सकता है।

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

एकीकरण परीक्षण

एकीकरण परीक्षणों की सहायता से, हम विभिन्न सेवाओं और डेटाबेस के साथ बातचीत की जाँच करते हैं।

कहानी को और समझने के लिए, आइए एक काल्पनिक प्रोमो विकसित करें और इसे परीक्षणों के साथ कवर करें। कल्पना करें कि हमारे उत्पाद प्रबंधकों ने हमारे सबसे समर्पित उपयोगकर्ताओं को सम्मेलन टिकट वितरित करने का निर्णय लिया:

प्रोमो दिखाया जाना चाहिए अगर:

क्षेत्र में उपयोगकर्ता "कार्य" इंगित करता है "प्रोग्रामर",
उपयोगकर्ता A / B परीक्षण HL18_promo में भाग लेता है,
उपयोगकर्ता दो साल से अधिक पहले पंजीकृत है।

"टिकट प्राप्त करें" बटन पर क्लिक करके, हमें इस उपयोगकर्ता के डेटा को कुछ सूची में सहेजना होगा ताकि इसे हमारे प्रबंधकों को स्थानांतरित किया जा सके जो टिकट वितरित करते हैं।

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

PHPUnit द्वारा प्रस्तुत डेटाबेस इंटरैक्शन का परीक्षण करने के मानक तरीके पर विचार करें:

परीक्षण डेटाबेस उठाएँ।
हम डेटाटेबल्स और डेटासेट तैयार करते हैं।
परीक्षण चलाएं।
हम परीक्षण डेटाबेस को साफ़ करते हैं।

इस तरह के दृष्टिकोण के इंतजार में क्या कठिनाइयाँ होती हैं?

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

इन समस्याओं से बचने के लिए, हमने अपनी छोटी सी लाइब्रेरी DBMocks विकसित की।

DBMocks

ऑपरेशन का सिद्धांत इस प्रकार है:

सॉफ्टमैक्स की मदद से हम उन सभी रैपरों को इंटरसेप्ट करते हैं जिनके माध्यम से हम डेटाबेस के साथ काम करते हैं।
जब
क्वेरी नकली के माध्यम से जाती है, SQL क्वेरी को पार्स करें और उसमें से DB + TableName खींचें, और कनेक्शन से होस्ट प्राप्त करें।
Tmpfs में एक ही मेजबान पर हम मूल एक के रूप में एक ही संरचना के साथ एक अस्थायी तालिका बनाते हैं (हम SHOW CREATE TABLE का उपयोग करके संरचना की नकल करते हैं)।
उसके बाद, हम सभी अनुरोधों को पुनर्निर्देशित करेंगे जो इस तालिका में नकली के माध्यम से नए सिरे से बनाए गए अस्थायी रूप से आएंगे।

यह हमें क्या देता है:

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

एपीआई परीक्षण

यूनिट और एपीआई परीक्षणों के बीच अंतर इस GIF द्वारा अच्छी तरह से चित्रित किया गया है:

लॉक ठीक काम करता है, लेकिन यह गलत दरवाजे से जुड़ा हुआ है।

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

उपयोगकर्ता पूल का परीक्षण करें

ऐसे परीक्षणों को सफलतापूर्वक लिखने के लिए हमें क्या करने की आवश्यकता है? आइए अपने प्रोमो दिखाने की शर्तों पर वापस जाएं:

क्षेत्र में उपयोगकर्ता "कार्य" इंगित करता है "प्रोग्रामर",
उपयोगकर्ता A / B परीक्षण HL18_promo में भाग लेता है,
उपयोगकर्ता दो साल से अधिक पहले पंजीकृत है।

जाहिर है, यहाँ सब कुछ उपयोगकर्ता के बारे में है। और वास्तव में, एपीआई परीक्षणों में 99% को एक अधिकृत पंजीकृत उपयोगकर्ता की आवश्यकता होती है, जो सभी सेवाओं और डेटाबेस में मौजूद है।

कहां से लाएं? आप इसे परीक्षण के समय पंजीकृत करने का प्रयास कर सकते हैं, लेकिन:

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

हमने एक टूल विकसित किया जिसे टेस्ट यूजर्स पूल कहा जाता है। यह दो विचारों पर आधारित है:

हम हर बार उपयोगकर्ताओं को पंजीकृत नहीं करते हैं, लेकिन कई बार इसका उपयोग करते हैं।
परीक्षण के बाद, हम उपयोगकर्ता डेटा को उसकी मूल स्थिति (पंजीकरण के समय) पर रीसेट कर देते हैं। यदि ऐसा नहीं किया जाता है, तो परीक्षण समय के साथ अस्थिर हो जाएंगे, क्योंकि उपयोगकर्ता अन्य परीक्षणों की जानकारी के साथ "प्रदूषित" होंगे।

यह कुछ इस तरह काम करता है:

कुछ बिंदु पर, हम एक उत्पादन वातावरण में अपने एपीआई परीक्षण चलाना चाहते थे। हम भी ऐसा क्यों चाहते हैं? क्योंकि डेवेल इन्फ्रास्ट्रक्चर उत्पादन के समान नहीं है।

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

इस मामले में, यह सोचना बहुत महत्वपूर्ण है कि परीक्षण उपयोगकर्ताओं को वास्तविक लोगों से अलग कैसे करें।

यदि परीक्षण उपयोगकर्ता हमारे आवेदन में वास्तविक दिखाई देने लगे तो क्या होगा।

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

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

क्यूए एपीआई

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

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

क्यूए एपीआई केवल परीक्षण उपयोगकर्ताओं के मामले में ही लागू किया जा सकता है: यदि कोई संगत झंडा नहीं है, तो परीक्षण तुरंत गिर जाएगा। यहां हमारी क्यूए एपीआई विधियों में से एक है जो आपको उपयोगकर्ता पंजीकरण तिथि को एक मनमाने ढंग से बदलने की अनुमति देती है:

और इसलिए यह तीन कॉल की तरह दिखेगा जो आपको परीक्षण उपयोगकर्ता के डेटा को जल्दी से बदलने की अनुमति देगा ताकि वे प्रोमोट की प्रदर्शन स्थितियों को संतुष्ट करें:

फ़ील्ड में "कार्य" "प्रोग्रामर" इंगित किया गया है:
addUserWorkEducation?user_id=ID&works[]=Badoo,
उपयोगकर्ता A / B परीक्षण HL18_promo में भाग लेता है:
forceSplitTest?user_id=ID&test=HL18_promo
दो साल से अधिक पहले पंजीकृत:
userCreatedChange?user_id=ID&created=2016-09-01

चूंकि यह एक पिछले दरवाजे है, इसलिए सुरक्षा के बारे में सोचना महत्वपूर्ण है। हमने अपनी सेवा को कई तरीकों से संरक्षित किया है:

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

RemoteMocks

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

हमारे पास तीन पाठ हैं:

Badoo एक बहुभाषी अनुप्रयोग है, हमारे पास एक जटिल स्थानीयकरण घटक है जो आपको उपयोगकर्ता के वर्तमान स्थान के लिए अनुवाद करने और अनुवाद प्राप्त करने की अनुमति देता है। हमारे स्थानीय लोग अनुवाद में सुधार करने के लिए लगातार काम कर रहे हैं, टोकन के साथ ए / बी परीक्षण करते हैं, और अधिक सफल योगों की तलाश करते हैं। और, परीक्षण करते समय, हम यह नहीं जान सकते कि कौन सा पाठ सर्वर द्वारा लौटाया जाएगा - यह किसी भी समय बदल सकता है। लेकिन स्थानीयकरण घटक को सही तरीके से एक्सेस किया गया है या नहीं, यह जांचने के लिए हम RemoteMocks का उपयोग कर सकते हैं।

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

यदि हम एक दूरस्थ मॉक बनाना चाहते हैं, तो हम संकेत देते हैं कि किस वर्ग या विधि को प्रतिस्थापित किया जाना चाहिए और किसके साथ। इस मॉक को ध्यान में रखते हुए सभी बाद के बैकेंड अनुरोधों को निष्पादित किया जाएगा:

 $this->remoteInterceptMethod( \Promo\HighLoadConference::class, 'saveUserEmailToDb', true );

ठीक है, अब चलो हमारे एपीआई परीक्षण इकट्ठा:

 //       $app_startup = [ 'supported_promo_blocks' => [\Mobile\Proto\Enum\PromoBlockType::GENERIC_PROMO] ]; $Client = $this->getLoginedConnection(BmaFunctionalConfig::USER_TYPE_NEW, $app_startup); //  $Client->getQaApiClient()->addUserWorkEducation(['Badoo, ']); $Client->getQaApiClient()->forceSplitTest('HL18_promo'); $Client->getQaApiClient()->userCreatedChange('2016-09-01'); //     $this->remoteInterceptMethod(\Promo\HighLoadConference::class, 'saveUserEmail', true); //,   ,   $Resp = $Client->ServerGetPromoBlocks([]); $this->assertTrue($Resp->hasMessageType('CLIENT_NEXT_PROMO_BLOCKS')); $PromoBlock = $Resp->CLIENT_NEXT_PROMO_BLOCKS; … //   CTA, ,   ,   $Resp = $Client->ServerPromoAccepted($PromoBlock->getPromoId()); $this->assertTrue($Resp->hasMessageType('CLIENT_ACKNOWLEDGE_COMMAND'));

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

एपीआई टेस्ट उपयोग नियम

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

यह बुरा क्यों है? क्योंकि API टेस्ट बहुत धीमे होते हैं। वे नेटवर्क पर जाते हैं, बैकएंड को चालू करते हैं, जो सत्र को चुनता है, डेटाबेस और सेवाओं का एक गुच्छा जाता है। इसलिए, हमने एपीआई परीक्षणों का उपयोग करने के लिए नियमों का एक समूह विकसित किया:

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

यूआई परीक्षण

चूंकि हम स्वचालन के पिरामिड पर विचार कर रहे हैं, इसलिए मैं आपको यूआई परीक्षणों के बारे में थोड़ा बताऊंगा।

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

हम मोबाइल ऑटो परीक्षणों के लिए कैलाब का उपयोग करते हैं, और वेब के लिए सेलेनियम का। यह स्वचालन और परीक्षण के लिए हमारे मंच के बारे में बात करता है।

टेस्ट रन

अब हमारे पास 100,000 यूनिट परीक्षण, 6,000 - एकीकरण परीक्षण और 14,000 एपीआई परीक्षण हैं। यदि आप उन्हें एक धागे में चलाने की कोशिश करते हैं, तो हमारी सबसे शक्तिशाली मशीन पर भी, सभी का एक पूरा भाग ले जाएगा: मॉड्यूलर - 40 मिनट, एकीकरण - 90 मिनट, एपीआई परीक्षण - दस घंटे। यह बहुत लंबा है।

साथ में चलाना

हमने इस लेख में इकाई परीक्षणों को समानांतर बनाने के हमारे अनुभव के बारे में बात की है।

पहला समाधान, जो स्पष्ट लगता है, कई थ्रेड्स में परीक्षण चलाना है। लेकिन हम आगे बढ़े और समानांतर लॉन्च के लिए एक क्लाउड बनाया जिससे हार्डवेयर संसाधनों को स्केल किया जा सके। सरलीकृत, उनका काम इस तरह दिखता है:

यहां सबसे दिलचस्प कार्य थ्रेड्स के बीच परीक्षणों का वितरण है, अर्थात्, विखंडू में उनका टूटना।

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

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

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

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

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

परिणामस्वरूप, यूनिट परीक्षण एक मिनट में, एकीकरण परीक्षण पाँच मिनट और एपीआई परीक्षण 15 मिनट में चलने लगे। यानी, 12 घंटे के बजाय एक पूर्ण रन 22 मिनट से अधिक नहीं लेता है।

कोड कवरेज परीक्षण चला

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

कुछ बिंदु पर, हम इस निष्कर्ष पर पहुंचे कि आपको हर बार सभी परीक्षण चलाने की आवश्यकता नहीं है - आप कोड कवरेज के आधार पर रन बना सकते हैं:

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

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

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

. , , , . . , code coverage . , , — , - , . .

API-, code coverage. , , . - , API- .

निष्कर्ष

, . - , , - .
≠ . code review , .
, , . .
. .
, ! , .

, Badoo PHP Meetup 16 . PHP-. , . ! 12:00, — YouTube- .

सैकड़ों क्लाइंट संस्करणों के लिए मोनोलिथ: हम परीक्षण कैसे लिखते हैं और समर्थन करते हैं