पूर्ण प्रतिक्रिया परीक्षण चक्र। Auto.ru रिपोर्ट

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



एलेक्स:
- पहले आपको थोड़ा सा बताना होगा कि ऑटोमोटिव न्यूज क्या है। यह एक साइट है जो कारों की बिक्री करती है। एक खोज, व्यक्तिगत खाता, कार सेवाएं, स्पेयर पार्ट्स, समीक्षा, डीलरशिप और बहुत कुछ है। Auto.ru एक बहुत बड़ी परियोजना है, बहुत सारे कोड। हम सभी कोड एक बड़े मोनोरेपे में लिखते हैं, क्योंकि यह सब मिश्रित है। वही लोग समान कार्य करते हैं, उदाहरण के लिए, मोबाइल और डेस्कटॉप के लिए। यह बहुत सारे कोड को बदल देता है, और मोनोरपा हमारे लिए महत्वपूर्ण है। सवाल यह है कि इसका परीक्षण कैसे किया जाए?



हमारे पास React और Node.js हैं, जो सर्वर-साइड रेंडरिंग करते हैं और बैकएंड से डेटा का अनुरोध करते हैं। बने और BEM पर छोटे टुकड़े।



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

रिलीज के उम्मीदवार को इकट्ठा करने के बाद, एक मैनुअल प्रतिगमन है - न केवल Auto.ru, बल्कि केवल वह पैकेज जिसे हम रोल करने जा रहे हैं। उदाहरण के लिए, यदि हम डेस्कटॉप वेब को रोल करने जा रहे हैं, तो डेस्कटॉप वेब का मैनुअल रिग्रेशन है। ये बहुत सारे मैनुअल टेस्ट केस हैं। इस तरह के एक प्रतिगमन ने एक मैनुअल परीक्षक के एक कार्य दिवस के बारे में लिया।

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



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

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

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

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

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



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



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



स्क्रीनशॉट परीक्षण भी हमेशा हमें अच्छी सटीकता नहीं देते हैं। यहां हम किसी तरह का कार्ड लोड करते हैं, यह थोड़ा स्थानांतरित हो गया है, हमारा परीक्षण गिर गया है।



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

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

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



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

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

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



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



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

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

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



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

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

यहां हम सिर्फ यह देखते हैं कि संपूर्ण रेंडरिंग, यह ठीक वैसा ही देता है जैसा कि MyComponent रिटर्न से रेंडर विधि, और सामान्य रूप से कौन सा फू है, यह ध्यान नहीं रखता है। हम अपने दो मामलों के लिए ऐसे दो परीक्षण लिख सकते हैं, हमारे दो मामलों के लिए MyComponent घटक के लिए।



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



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



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





उसी तरह, हम फू घटक पर इकाई परीक्षण लिखेंगे, बार घटक पर, उदाहरण के लिए, स्नैपशॉट।



हमें इन तीन घटकों के लिए 100% कवरेज मिलता है। हम मानते हैं कि हमने सब कुछ जांच लिया है, हम अच्छी तरह से कर रहे हैं।

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



लेकिन वास्तव में, अगर हम इस पूरी कहानी को इकट्ठा करते हैं, तो कुछ भी काम नहीं करेगा, क्योंकि MyComponent को ऐसी त्रुटि के साथ नहीं मिलेगा। हम वास्तव में उस प्रस्ताव को पारित नहीं करते हैं जिसकी वह बार घटक से अपेक्षा करता है। इसलिए, हम इस तथ्य के बारे में बात कर रहे हैं कि इस मामले में हमें एकीकरण परीक्षणों की भी आवश्यकता है, जिसमें यह जांच शामिल है कि क्या हम अपने घटक से उसके बच्चे के घटक को सही ढंग से कहते हैं।



इस तरह के घटक होने और उनमें से एक को बदलने के बाद, आप तुरंत देखते हैं कि इस घटक में क्या परिवर्तन हुए हैं।

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



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



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



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



उथले प्रतिपादन में, आप एक घटक को स्टोर पास कर सकते हैं। यदि आपको स्टोर की आवश्यकता है, तो आप इसे वहां स्थानांतरित कर सकते हैं, और यह काम करेगा।



आप पहले से ही दिए गए घटक में स्थिति और प्रस्ताव को बदल सकते हैं।



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



एलेक्स:
- हम सबसे दिलचस्प सवाल पर आते हैं। हम जेस्ट का परीक्षण कर सकते हैं, हम यूनिट टेस्ट लिख सकते हैं, घटकों की जांच कर सकते हैं, जांच सकते हैं कि कौन से तत्व एक क्लिक पर गलत तरीके से प्रतिक्रिया करते हैं। हम उनके html की जांच करने में सक्षम हैं। अब हमें घटक के लेआउट की जांच करने की आवश्यकता है, सीएसएस।



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



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

सवाल यह है कि अगर मैं अलगाव में केवल एक घटक की जांच करना चाहता हूं तो पृष्ठ html क्या है? यह वांछनीय है - विभिन्न स्थितियों में।

^{_{स्लाइड से लिंक करें}}

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

^{_{स्लाइड से लिंक करें}}

और फिर उन्होंने एक विशेष सर्वर उठाया, वहां html भेजें, यह इसे प्रदान करता है, और कुछ परिणाम देता है। एक बहुत ही दिलचस्प लेख, पढ़ें, हालांकि, आप वहां से बहुत सारे दिलचस्प विचार आकर्षित कर सकते हैं।



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

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



लेकिन यह समस्या html के साथ है, यह वही है जो वास्तव में है। और एक विचार पैदा हुआ। आपके पास ऐसा सरलीकृत webpack.conf है, और इसमें से क्लाइंट js के लिए कुछ एंट्रीप्वाइंट है। मॉड्यूल वर्णित हैं, उन्हें कैसे इकट्ठा किया जाए, आउटपुट फ़ाइल, आपके द्वारा वर्णित सभी प्लगइन्स, सब कुछ कॉन्फ़िगर किया गया है, सब कुछ ठीक है।



अगर मैं ऐसा करूँ तो क्या होगा? वह मेरे घटक में जाएगा और इसे अलगाव में एकत्र करेगा। और ठीक एक घटक होगा। अगर मैं वहाँ html वेबपैक जोड़ता हूँ, तो यह मुझे html भी देगा, और ये संपत्तियाँ वहाँ एकत्र की जाएँगी, और इस चीज़ को, पहले से ही स्वचालित रूप से परखा जा सकता है।

और मैं यह सब लिखने वाला था, लेकिन तब मुझे यह पता चला।



Jest-puppeteer-React, एक युवा प्लगइन। और मैंने इसे सक्रिय रूप से योगदान देना शुरू कर दिया। यदि आप अचानक कोशिश करना चाहते हैं, तो आप उदाहरण के लिए, मेरे पास आ सकते हैं, मैं किसी तरह मदद कर सकता हूं। परियोजना, वास्तव में, मेरी नहीं है।

आप test.js के रूप में एक नियमित फ़ाइल लिखते हैं, और इन फ़ाइलों को खोजने में मदद करने के लिए उन्हें थोड़ा अलग से लिखने की आवश्यकता होती है, ताकि आप के लिए पूरी परियोजना को संकलित न करें, लेकिन केवल आवश्यक घटकों को संकलित करने के लिए। वास्तव में, आप वेबपैक कॉन्फ़िगरेशन लेते हैं। और इनपुट पॉइंट इन ब्राउजर में बदल जाते हैं। जेएस फाइल्स, यानी हम जो टेस्ट करना चाहते हैं, उसी को html में पैक किया जा सकता है, और Puppeteer की मदद से यह आपको स्क्रीनशॉट लेगा।



वह क्या कर सकता है? , jest-image-snapshot. . , , js, media-query, , .

headless-, , , , , headless-, Chrome . web-, , , , .

Docker. . . , Docker, . . Docker , , , Linux, - , - . Docker , .



? , . , . before-after, , . , . , Chrome, Firefox. .

. pixelmatch. , looksame, «», . , .



— . , , . , : - , — Enzyme. Redux store . . viewport, , . , , .



. , . ? , .



: 5-10 . Selenium . , , , . .



Puppeteer, e2e-. , e2e- — , Selenium.

:
— , Selenium Java , . - JS Puppeteer, , .

, . , , .



— Selenium Java, — JS Puppeteer. . 18 . , , Java. , , Java Selenium.



:
— ? . , html-, css . e2e. . , .



, , . . , , — , . , . - , , : , .

, , . git hook, -, . green master — , , , . आपका धन्यवाद