स्वागत! मेरी Vuejs एम्स्टर्डम सम्मेलन 2022 सारांश श्रृंखला के छठे भाग में आपको देखकर खुशी हुई, जिसमें मैं आपके साथ सभी वार्ताओं का सारांश साझा करता हूं। आप मेरी जेएसवर्ल्ड सम्मेलन 2022 सारांश श्रृंखला (चार भागों में) पढ़ सकते हैं, जहां मैंने पहले दिन की सभी वार्ताओं का सारांश दिया था। आप मेरे ब्लॉग में Vue एम्स्टर्डम सम्मेलन 2022 की पिछली वार्ता भी पा सकते हैं। यहां (आवर्ती) परिचय ढाई साल के बाद, 1 और 3 जून के बीच JSWorld और Vue एम्स्टर्डम सम्मेलन थिएटर एम्स्टर्डम में वापस आ गए, और मुझे पहली बार इस सम्मेलन में भाग लेने का मौका मिला। मैंने बहुत सी चीजें सीखीं, कई अद्भुत लोगों से मुलाकात की, महान डेवलपर्स के साथ बात की, और बहुत अच्छा समय बिताया। पहले दिन JSWorld सम्मेलन आयोजित किया गया था, और दूसरे और तीसरे दिन, Vue एम्स्टर्डम। सम्मेलन महान वक्ताओं के साथ जानकारी से भरा था, जिनमें से प्रत्येक ने मुझे कुछ मूल्यवान सिखाया। वे सभी अपने ज्ञान और जानकारी को अन्य डेवलपर्स के साथ साझा करना चाहते थे। इसलिए मैंने सोचा कि यह बहुत अच्छा होगा अगर मैं इसे साझा करना जारी रख सकूं और दूसरों को इसका इस्तेमाल करने में मदद कर सकूं। सबसे पहले, मैंने कुछ नोट्स या स्लाइड साझा करने की कोशिश की, लेकिन मुझे लगा कि यह काफी अच्छा नहीं था, कम से कम उतना अच्छा नहीं जितना कि स्पीकर ने मेरे साथ साझा किया। इसलिए मैंने प्रत्येक भाषण को फिर से देखने, उनमें गहराई तक जाने, खोज करने, नोट्स लेने और उन्हें उनकी स्लाइडों और यहां तक कि उनके भाषण में उनके सटीक शब्दों के साथ संयोजित करने और फिर इसे आपके साथ साझा करने का निर्णय लिया ताकि जो मैं आपके साथ साझा कर रहा हूं वह कम से कम उसी स्तर पर जो मैंने उनसे सीखा। एक बहुत ही महत्वपूर्ण बिंदु और मैंने केवल उन्हें सीखने की कोशिश की है ताकि मैं उन्हें इन लेखों में बदल सकूं। यहां तक कि इसका मतलब है कि अगर आप कुछ नया सीखते हैं, तो यह उनके प्रयासों के कारण होता है। (तो अगर आप कुछ गलत सूचना देखते हैं तो उन्हें दोष दें, मुझे नहीं, ठीक है? xD) इन चंद लेखों के दौरान आपने जो कुछ भी पढ़ा, वह स्वयं वक्ता के प्रयास और समय का परिणाम है, इन लेखों में लिखे गए कई वाक्य ठीक वही हैं जो उन्होंने कहा या स्लाइड में लिखा है। अंतिम लेकिन कम से कम, मैं कुछ भाषणों में हर तकनीकी विवरण या लाइव कोडिंग में खुदाई नहीं कर सकता। लेकिन अगर आप रुचि रखते हैं और अधिक जानकारी चाहते हैं, तो मुझे बताएं और मैं अलग से एक और विस्तृत लेख लिखने की कोशिश करूंगा। साथ ही, उनका ट्विटर/लिंक्डिन देखना न भूलें। आप सम्मेलन का कार्यक्रम देख सकते हैं। यहां यह एक (परीक्षण) जाल है! सामान्य परीक्षण नुकसान और उन्हें कैसे हल करें - Shopware में सॉफ़्टवेयर डेवलपर Ramona Schwering "यह एक जाल है" - एक कॉल या भावना जिससे हम सभी परिचित हो सकते हैं, न कि केवल जब स्टार वार्स की बात आती है। यह आसन्न खतरे को नोटिस करने के अचानक क्षण का संकेत दे रहा है। परीक्षण में अप्रिय अहसास के लिए यह स्थिति एक उत्कृष्ट रूपक है। कल्पना कीजिए कि जब परीक्षण की बात आती है तो सबसे अच्छे इरादे होते हैं, लेकिन फिर भी परीक्षणों के साथ समाप्त होने से आपको कोई मूल्य नहीं मिलता है? ऐसे टेस्ट जिनसे निपटने में दर्द महसूस हो रहा है? फ्रंटएंड टेस्ट लिखते समय, रास्ते में बहुत सारे नुकसान होते हैं। संक्षेप में, वे घटिया रख-रखाव, धीमी निष्पादन समय, और - सबसे खराब स्थिति में - ऐसे परीक्षण कर सकते हैं जिन पर आप भरोसा नहीं कर सकते। लेकिन सबसे खराब स्थिति वे परीक्षण हैं जो आपको नए मूल्य और परिणाम देते हैं क्योंकि वे परतदार होते हैं। आपके पास एक निर्माण है जो कभी-कभी गुजरता है और कभी-कभी विफल हो जाता है और आपने बीच में कुछ नहीं किया। पैन पॉइंट्स आप निश्चित हो सकते हैं कि परीक्षण के कई लाभ और लाभ हैं, लेकिन उन सभी अद्भुत चीजों को विभिन्न कारणों से होने वाले दर्द बिंदुओं से छायांकित किया जा सकता है। सभी चीजें जो आपने अच्छे इरादों के साथ कीं, लेकिन लंबे समय में या उससे भी पहले वे दर्दनाक या थकाऊ निकलीं। उदाहरण के लिए, धीमे परीक्षण मज़ा को मार सकते हैं। कल्पना कीजिए कि आपके पास आपका पुल अनुरोध है और आप इसे विलय करना चाहते हैं, लेकिन पाइपलाइन के अंत में पूरा होने के लिए आपको घंटों या शायद दिनों की प्रतीक्षा करनी होगी। इससे भी बदतर परीक्षण ऐसे होते हैं जिन्हें बनाए रखना दर्दनाक होता है। आप अपने अतीत के बारे में सोचते हैं और पूछते हैं: आपने इस परीक्षा के साथ क्या किया? उद्देश्य क्या था?! आपने उस के बारे में क्या सोचा? या टीम के अन्य सदस्य जो आपसे सवाल पूछ रहे हैं कि आपने अतीत में क्या किया और आपको कोई जानकारी नहीं है। लेकिन सबसे खराब स्थिति वे परीक्षण हैं जो आपको नए मूल्य और परिणाम देते हैं क्योंकि वे परतदार होते हैं। आपके पास एक निर्माण है जो कभी-कभी गुजरता है और कभी-कभी विफल हो जाता है और आपने बीच में कुछ नहीं किया। सरल परीक्षण यह इस तरह होना जरूरी नहीं है। जावास्क्रिप्ट परीक्षण सर्वोत्तम प्रथाओं में सबसे महत्वपूर्ण मानसिकता और सुनहरे नियमों में से एक सरल है। परीक्षणों को हर मामले में सादा और सरल बनाया जाना चाहिए। यूनिट टेस्ट, इंटीग्रेशन टेस्ट और एंड टू एंड टेस्ट में, इसे सरल रखें। हमारा लक्ष्य यह होना चाहिए कि कोई आपके परीक्षण को समझने में सक्षम हो और इसके बारे में सोचे बिना तुरंत अपना इरादा प्राप्त कर सके। एक सपाट परीक्षण डिजाइन के लिए लक्ष्य बनाने का प्रयास करें, जिसका अर्थ है कि केवल उतना ही परीक्षण करना जितना आवश्यक है और कुछ या बिना किसी सार का उपयोग करना। जाल आइए पहले ट्रैप को देखें। describe('deprecated.plugin', () => { it('should throw error',() => { … }); }); यदि बहिष्कृत प्लगइन उपयोग में है तो इसे एक त्रुटि फेंकनी चाहिए। जब आप शीर्षक को देखते हैं - एक त्रुटि फेंकनी चाहिए - आप नहीं जानते कि यह क्या हासिल करना चाहता है। लेकिन सुनहरा नियम कहता है कि आपको तुरंत पता होना चाहिए कि यह क्या कर रहा है। हम इसे "तीन-भाग नियम" के साथ और अधिक सुगम बना सकते हैं। परीक्षण शीर्षक में तीन चीजें होनी चाहिए: क्या परीक्षण किया जा रहा है किन परिस्थितियों में परीक्षण किया जाना चाहिए परिणाम की क्या उम्मीद है इस नियम को ध्यान में रखते हुए, हमारा परीक्षण ऐसा दिखाई देगा: describe('deprecated.plugin', () => { it('Property: Should throw an errorif the deprecated prop is used', () => { … }); }); अगला ट्रैप परीक्षण संरचना हो सकता है: describe('Context menu', () => { it('should open the context menu on click', async () => { const wrapper = createWrapper(); expect(wrapper.vm).toBeTruthy(); await wrapper.trigger('click'); const selector = '.sw-context-menu'; expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); }); इस मामले में, बिना किसी स्पष्ट संरचना के सभी जगह घोषणाएं, क्रियाएं और दावे लिखे गए हैं। विशेष रूप से बड़े परीक्षणों में, यह बहुत बड़ा दर्द हो सकता है। हम इसे एएए पैटर्न के साथ और अधिक संरचित बना सकते हैं। आप अपने परीक्षण को तीन भागों में विभाजित करते हैं: व्यवस्था करें: सेटअप से संबंधित सब कुछ परिदृश्य के लिए परीक्षण का उद्देश्य अनुकरण करना है। क्रियाएँ: अपनी इकाई को परीक्षण पर चलाना और परिणाम स्थिति में लाने के लिए कदम उठाना। जोर दें: जहां आप अभिकथन कर सकते हैं और अपने परीक्षण परिदृश्य की जांच कर सकते हैं। एएए पैटर्न के साथ हमारा परीक्षण ऐसा दिखता है: describe('Context menu', () => { it('should open the context menu on click', () => { // Arrange const wrapper = createWrapper(); const selector = '.sw-context-menu'; // Act await wrapper.trigger('click'); // Assert expect(wrapper.vm).toBeTruthy(); expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); }); यह बहुत बेहतर दिखता है! लेकिन एक समस्या है। हमारे परीक्षण मामले पर वापस सोचें। यह एक संदर्भ मेनू है और यह डिफ़ॉल्ट रूप से छिपा हुआ है। इसलिए हमें इसके साथ बातचीत करने के लिए इसे खोलने की जरूरत है। लेकिन इसका मतलब है कि हमें यह सुनिश्चित करने के लिए एक अभिकथन करने की आवश्यकता है कि यह अधिनियम से पहले खुला है। क्या यह पैटर्न को नष्ट नहीं करता है? यदि हम DOM का परीक्षण कर रहे हैं, तो हमें कभी-कभी पहले और बाद की अवस्थाओं की जाँच करने की आवश्यकता होती है। तो आइए इस पैटर्न को दूसरे नजरिए से देखें। ...मेरे परीक्षण की व्यवस्था करें == जो मुझे । दिया गया है ... मेरे परीक्षण में कार्य करें == कुछ होता है। जब …परिणामों पर जोर दें == कुछ होता है परिणाम के रूप में मैं यही उम्मीद करता हूं। तो यह व्यवहार संचालित विकास से लिया गया एक पैटर्न है: दिया गया - कब - तब इस पैटर्न के उपयोग के साथ हमारा पूर्व परीक्षण: describe('Context menu', () => { it('should open the context menu on click', () => { // Given const contextButtonSelector = 'sw-context-button'; const contextMenuSelector = '.sw-context-menu'; // When let contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(false); const contextButton = wrapper.find(contextButtonSelector); await contextButton.trigger('click'); // Then contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(true); }); }); E2E परीक्षण प्लेसहोल्डर का उपयोग करने से बचें और यथासंभव यथार्थवादी नामकरण का उपयोग करें। it('should create and read product', () => { … cy.get('.sw-field—product-name').type('T-Shirt Ackbar'); cy.get('.sw-select-product__select_manufacturer') .type('Space Company'); … }); यदि आप हजारों नामों के साथ नहीं आना चाहते हैं, तो हो सकता है कि आप कुछ डमी डेटा उत्पन्न करने के लिए फ़ेकर या अन्य टूल का उपयोग कर सकते हैं, या यदि यह कानूनों और आपकी परियोजना के साथ ठीक है, तो इसे उत्पादन स्थिति से आयात करें। बस यह सुनिश्चित करें कि आपका परीक्षण बोधगम्य और पढ़ने में आसान हो और आपको पता हो कि यह क्या करता है। आइए अगले ट्रैप के लिए उसी टेस्ट पर एक नजर डालते हैं, जो चयनकर्ता है। यदि आप अपने आवेदन को रिफलेक्टर करते हैं और कुछ वर्गों को बदलते हैं - जो कि सामान्य है - इससे आपका परीक्षण विफल हो सकता है, और इस मामले में, आपके ऐप में मौजूद बग के बिना परीक्षण विफल हो जाता है - जिसे एक गलत नकारात्मक कहा जाता है जो आपकी कोई विश्वसनीय रिपोर्ट नहीं देता है app क्योंकि यह टूटा नहीं है, बस आपका कार्यान्वयन बदल गया है। उन चयनकर्ताओं को देखें जिन्हें आपको अवश्य देखना चाहिए! दूसरे शब्दों में, आपको कार्यान्वयन विवरण का परीक्षण नहीं करना चाहिए। इसके बजाय, उन चीज़ों का उपयोग करने के बारे में सोचें जिन पर उपयोगकर्ता ध्यान आकर्षित करेगा और आपके एप्लिकेशन को नेविगेट करेगा। उदाहरण के लिए आपके पृष्ठ के अंदर कुछ पाठ। इससे भी बेहतर, उन चयनकर्ताओं का उपयोग करें जिनमें परिवर्तन की संभावना नहीं है, जैसे डेटा विशेषताएँ। आप इसे उदाहरण के लिए सरू के लिए भी कह सकते हैं, ताकि कोई तुरंत जान सके कि यह परीक्षण के लिए है। data-cy=”submit” अंतिम लेकिन कम से कम, निश्चित प्रतीक्षा समय का उपयोग न करें। Cypress.Commands.add('typeSingleSelect', { prevSubject: 'element', }, (subject, value, selector) => { … cy.wait(500); cy.get(`${selector} input`) .type(value); }); एक तरफ, यह आपके परीक्षण के तरीके को बहुत धीमा कर सकता है यदि एक परीक्षण मामले को कई बार निष्पादित किया जाएगा। यह तब और भी बुरा हो सकता है जब आपके एप्लिकेशन का उपयोग कमजोर हार्डवेयर पर किया जा रहा हो। इस मामले में, आपको उस फिक्स 500ms से अधिक की आवश्यकता हो सकती है। इसके लिए कुछ समाधान हैं, उदाहरण के लिए UI में परिवर्तनों की प्रतीक्षा करना, जैसे लोडिंग स्पिनर के गायब होने के लिए या रोकने के लिए एक एनीमेशन या कुछ दिखाई देने के लिए। या इससे भी बेहतर, एपीआई अनुरोधों और प्रतिक्रियाओं की प्रतीक्षा करें। टेस्ट आपके लिए एक सहायक के रूप में हैं, बाधा नहीं। उन्हें एक दिनचर्या की तरह महसूस करना चाहिए, न कि एक जटिल गणितीय सूत्र को हल करना। छठी वार्ता का अंत मुझे आशा है कि आपको यह भाग पसंद आया होगा और यह आपके लिए उतना ही मूल्यवान हो सकता है जितना कि यह मेरे लिए था। अगले कुछ दिनों में, मैं बाकी की बातचीत आपके साथ साझा करूँगा। बने रहें… भी प्रकाशित हो चुकी है।. यहाँ
