ऑटोटेस्ट्स के तीन साल: कैसे गति बढ़ाने के लिए और न केवल

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

शुरुआत करने के लिए, लेख में जिन शब्दों पर चर्चा की जाएगी:

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

विभिन्न प्रकार के परीक्षणों के पेशेवरों और विपक्ष

स्वीकृति परीक्षण

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

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

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

कार्यात्मक परीक्षण एक मध्यवर्ती समाधान है।

• पेशेवरों: अधिक विश्वसनीय स्वीकृति, मॉड्यूलर की तुलना में कोड की संरचना में परिवर्तन के लिए अधिक प्रतिरोधी।
• विपक्ष: मॉड्यूलर की तुलना में धीमी, लिखने में अधिक कठिन, क्योंकि एक बड़ी स्थिरता तैयार करने की जरूरत है।

गति के लिए लड़ाई

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

पहला अनुभव: मोकी

PhpUnit में Mock एक गतिशील रूप से बनाई गई वस्तु है जिसका वर्ग गतिशील रूप से पैरोडीड क्लास से विरासत में मिला है। आप कॉन्फ़िगर कर सकते हैं कि मोक के कौन से तरीके वापस आएंगे, आप जाँच सकते हैं कि मोके के कौन से तरीके कितनी बार किन मापदंडों से कहे गए थे

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

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

माइनस : परीक्षण कोड कार्यान्वयन से बहुत जुड़ा हुआ है। परीक्षण के दौरान, हमें एक मॉक ऑब्जेक्ट बनाना चाहिए और इस बारे में सोचना चाहिए कि इस पर क्या तरीके कहे जाने चाहिए।

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

मैं परीक्षण में तेजी लाने के मामले में मोक के साथ अनुभव को असफल मानता हूं।

अनुभव दो: SQLite

अगला विकल्प SQLite DBMS है , यह RAM में एक डेटाबेस बना सकता है। मुझे SQLite में एक PostgreSQL अनुवादक स्कीमा लिखना था, प्रत्येक माइग्रेशन के बाद एक नया SQLite स्कीमा उत्पन्न किया गया था। इस सर्किट के परीक्षणों ने RAM में एक खाली डेटाबेस बनाया। इस दृष्टिकोण ने स्थानीय मशीनों पर परीक्षणों की गति को दो से चार गुना तक बढ़ा दिया। यह प्रति घंटे कई बार पूरे परीक्षण सूट को चलाने के लिए वास्तविक बन गया।

लेकिन विपक्ष थे। हमने कई मूल PostgreSQL फीचर्स (json, कुछ आसान कुल कार्य, और बहुत कुछ) खो दिए हैं। क्वेरीज़ को लिखना पड़ा ताकि वे PostgreSQL और SQLite दोनों पर काम करें।

तीन अनुभव: PostgreSQL अनुकूलन

यह निर्णय काम कर रहा था, लेकिन कुछ दर्द का कारण बना। कुछ बिंदु पर, हमें पता चला कि पोस्टग्रैसीक्यू को ऑटोटेस्ट के लिए अनुकूलित किया जा सकता है, जो प्रतिक्रिया समय को लगभग चार गुना कम कर देता है। ऐसा करने के लिए, postgresql.conf में कुछ सेटिंग्स जोड़ें:

fsync=off synchronous_commit=off full_page_writes=off 

ये विश्वसनीयता सेटिंग्स हैं, वे गारंटी देते हैं कि यदि सर्वर लेनदेन के बीच में मर जाता है, तो यह सही ढंग से समाप्त हो जाएगा जब सब कुछ फिर से काम करना शुरू कर देगा। यह स्पष्ट है कि ऐसी सेटिंग्स उत्पादन पर नहीं बनाई जा सकती हैं, लेकिन यह स्वचालित परीक्षणों पर सुविधाजनक था।

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

थोड़ा new बारे में

मैं new ऑपरेटर के खतरे का भी उल्लेख करना चाहूंगा। इसकी मदद से बनाई गई सेवाओं को मोक और स्टब्स द्वारा प्रतिस्थापित नहीं किया जा सकता है। निष्कर्ष:

• अनिवार्य रूप से सेवाओं वाले ऑब्जेक्ट बनाने के लिए new का उपयोग न करें।
• इसका उपयोग कारखानों में किया जा सकता है, क्योंकि उन्हें प्रतिस्थापित किया जा सकता है। लेकिन खुद कारखानों को new माध्यम से नहीं बनाया जाना चाहिए।
• इसका उपयोग मॉडल, इकाइयां, डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट), मूल्य-ऑब्जेक्ट बनाने के लिए किया जा सकता है।

तीन साल के अनुभव से निष्कर्ष

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