हमने 12 बार परीक्षणों को कैसे तेज किया इसकी कहानी

परीक्षणों को गति दें, उन्होंने कहा।

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

जो लोग नहीं जानते हैं, उनके लिए घटक परीक्षण ऐसे परीक्षण हैं जो वैश्विक वातावरण से पूरी तरह अलग-थलग हैं और आपको कुछ मामलों की जाँच करने की अनुमति देते हैं जिन्हें एक इकाई परीक्षण कवर नहीं कर सकता है।

छह महीने पहले, एक सुविधा के जारी होने में एक घंटे से अधिक समय लगता था, यह देखते हुए कि कोड का परीक्षण लंबे समय से पहले से ही पूरी तरह से किया गया है, लेकिन मास्टर शाखा बांस में ग्रीन बिल्ड को प्राप्त नहीं कर सकती है, और फिर सवाल उठता है: कैसे जीना है?

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

1. टीम का नेतृत्व
2. बैकएंड डेवलपर
3. क्यूए इंजीनियर
4. व्यवस्थापक

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

विकास की शुरुआत में, हमारे पास 140 + कार्यात्मक परीक्षण थे जो विभिन्न वातावरणों (फ्रंटेंड, मोबाइल, बैकएंड) के तहत कई थ्रेड्स में चलाए गए थे और उन्हें ~ 5-7 मिनट लगे; हरे रंग के निर्माण को प्राप्त करने के लिए भी अक्सर उन्हें पुनः आरंभ करना पड़ता था। और ये परीक्षण नए लिखित कोड के कारण नहीं रह गए थे, लेकिन पर्यावरण में समस्याओं के कारण, यानी, कहीं एपीआई ने जवाब नहीं दिया, कहीं परीक्षण माइक्रोसेवर गिर गया, आदि। इसने पूरे विभाग के काम को रोक दिया, क्योंकि विधानसभाएं लगभग हर 5-10 मिनट में शुरू हुईं: किसी ने भरोसा किया, किसी ने एक नया कोड दिया ...

सप्ताह की पहली छमाही के बाद, हम इस निष्कर्ष पर पहुंचे कि हम अपनी एपीआई और तीसरे पक्ष की सेवाओं को "गीला कर देंगे", जो हमें पूरी तरह से पृथक परीक्षण वातावरण प्रदान करेगा। लेकिन सवाल उठता है: अपने स्वयं के कुछ लिखने के लिए ... तो, इस पर "या" सब कुछ समाप्त हो गया - एक छोटी खोज के साथ, मेरे रास्ते में मैं मिला - मॉक सर्वर "http-api-mock" के रूप में एक छोटा सा ऑपरेटिंग समय।

http-api-mock एक लाइटवेट और इंस्टॉलेशन-फ्री मॉक सर्वर है जिसे गो के साथ अच्छे डॉक्यूमेंटेशन में लिखा गया है।

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

बेस हेल्पर क्लास हमारे मॉक सर्वर की कॉन्फिग डायरेक्टरी में एक जोंस फाइल के रूप में एक विज्ञापन बना सकती है, इडी द्वारा वांछित विज्ञापन दे सकती है, आदि। लगभग एक एपीआई।

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

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

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

# Delete/Create network docker network rm mock-kolesa-net; docker network create --subnet=IP_ADDR/24 --gateway IP_ADDR_GATEWAY mock-kolesa-net; # Docker run http-mock-kolesa docker run \ --rm \ --name http-mock-kolesa -d \ -v ${CONFIG}/config/:/config \ -v ${CONFIG}/data/:/data \ --user $(id -u):$(id -g) \ --net mock-kolesa-net \ --ip IP_ADDR\ local-docker-hub.kolesa-domain.org:7979/build/http-mock-kolesa; 

अब हमारे कोड के लिए एक पूरी तरह से नया एपीआई है, जो किसी भी पर्यावरणीय समस्याओं की परवाह किए बिना, हमें वह देगा जो हम चाहते हैं।

समय बीत गया, परीक्षण फिर से लिखे गए, और 140 कार्यात्मक परीक्षण 103 घटक परीक्षणों में बदल गए, जो ~ 30 सेकंड में समानांतर में चलते हैं।

पेशेवरों की

बहुत फुर्तीला । इस तथ्य के कारण कि वे परीक्षण वातावरण से पूरी तरह से स्वतंत्र हैं, उन्हें डेटा के लिए दूर नहीं जाना पड़ता है।

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

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

माइनस के

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

फाइलों का एक गुच्छा । उन्होंने फ़ाइलों के रूप में डेटा को कॉन्फ़िगर करने का निर्णय लिया, अर्थात्, समापन बिंदु के लिए प्रत्येक उत्तर फ़ाइल के रूप में निहित है और कहीं खो सकता है।

परिणाम:

परीक्षण
यह था: 140+ कार्यात्मक परीक्षण = 5-7 मिनट।
अब: 103 घटक परीक्षण = ~ 30 सेकंड।

स्थिरता का निर्माण करें
यह था: किसी भी समस्याओं के कारण हर तीसरी विधानसभा गिर गई।
यह बन गया: केवल तभी जब डेवलपर ने किसी विधि के तर्क को तोड़ दिया।

भविष्य की योजनाओं में हमें स्वीकृति (गुई) परीक्षणों को फिर से लिखना है - उन्हें कंटेनर के अंदर भी चलाएं और उन्हें बाकी पर्यावरण से अलग करें।