उत्परिवर्तन विश्लेषण, या परीक्षण का परीक्षण कैसे करें

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



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


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

अपने खाली समय में, मार्क क्रासनोडर देवोदर डेवलपर डेज़ विकसित करता है, 19 आईटी समुदायों में से एक है, जिनके कार्यकर्ताओं को हमने मॉस्को में फ्रंटेंड कॉन्फ में आमंत्रित किया है।

परीक्षण

स्वचालित परीक्षण के विभिन्न प्रकार हैं।


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

इससे बचने के लिए, हम एकीकरण परीक्षण लिख सकते हैं जो हमारे मॉड्यूल के संचालन को एक साथ परीक्षण करेंगे।


वे थोड़े अधिक जटिल हैं, इसलिए आज हम इकाई परीक्षण पर ध्यान देंगे।

इकाई परीक्षण

कोई भी परियोजना जो कम से कम कुछ न्यूनतम स्थिरता चाहती है, इकाई परीक्षण लिख रही है।

एक उदाहरण पर विचार करें।

class Signal { on(callback) { ... } off(callback) { const callbackIndex = this.listeners.indexOf(callback); if (callbackIndex === -1) { return; } this.listeners = [ ...this.listeners.slice(0, callbackIndex - 1), ...this.listeners.slice(callbackIndex) ]; } trigger() { ... } } 

एक सिग्नल क्लास है - यह एक इवेंट एमिटर है, जिसमें सदस्यता के लिए एक विधि है और सदस्यता को हटाने के लिए एक बंद विधि है - हम जांचते हैं कि क्या कॉलबैक सब्सक्राइबर सरणी में निहित है, तो इसे हटा दें। और, ज़ाहिर है, एक ट्रिगर विधि है जो हस्ताक्षरित कॉलबैक को कॉल करेगी।

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

 test('off method should remove listener', () => { const signal = new Signal(); let wasCalled = false; const callback = () => { wasCalled = true; }; signal.on(callback); signal.off(callback); signal.trigger(); expect(wasCalled).toBeFalsy(); }); 

गुणवत्ता मूल्यांकन मानदंड

ऐसे परीक्षण की गुणवत्ता का आकलन करने के लिए क्या मानदंड हैं?

कोड कवरेज सबसे लोकप्रिय और अच्छी तरह से ज्ञात मानदंड है जो दिखाता है कि परीक्षण चलाने के दौरान कोड की कितनी प्रतिशत लाइनों को निष्पादित किया गया था।


आपके पास 70%, 80%, या सभी 90% कोड कवरेज हो सकता है, लेकिन क्या इसका मतलब यह है कि जब आप उत्पादन के लिए अगले निर्माण को इकट्ठा करते हैं, तो सब कुछ ठीक होगा, या कुछ गलत हो सकता है?

आइए अपने उदाहरण पर वापस जाएं।

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

  ...this.listeners.slice(0, callbackIndex - 1), ...this.listeners.slice(callbackIndex) 

आपने तय किया कि आप संभवतः केवल सरणी को साफ़ कर सकते हैं:

 class Signal { ... off(callback) { const callbackIndex = this.listeners.indexOf(callback); if (callbackIndex === -1) { return; } this.listeners = []; } ... } 

मैंने प्रतिबद्ध किया, परियोजना को इकट्ठा किया और इसे उत्पादन के लिए भेजा। टेस्ट पास हुआ - क्यों नहीं? और वह एक बार में आराम करने चला गया।



लेकिन अचानक, देर रात, रिसीवर में एक कॉल आया, कि सब कुछ गिर रहा था, लोग उत्पाद का उपयोग नहीं कर सकते थे, और सामान्य तौर पर, व्यापार ने पैसे बर्बाद किए! आप जलते हैं, आपको बर्खास्तगी की धमकी दी जाती है।



इससे कैसे निपटें? परीक्षणों के साथ क्या करना है? ऐसी आदिम मूर्खतापूर्ण गलतियों को कैसे पकड़ा जाए? परीक्षणों का परीक्षण कौन करेगा?

बेशक, आप क्यूए इंजीनियरों की एक सेना को काम पर रख सकते हैं - उन्हें बैठने दें और बस हमारे आवेदन को ताली बजाएं।



या क्यूए स्वचालन को किराए पर लें। उन्हें लेखन परीक्षणों पर दोषी ठहराया जा सकता है - यदि इसके लिए विशेष लोग हैं तो अपने दम पर क्यों लिखें?

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

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

यह हमारे परीक्षणों की परीक्षण प्रक्रिया को स्वचालित करने का एक तरीका है। इसका उद्देश्य अप्रभावी और अपूर्ण परीक्षणों की पहचान करना है, अर्थात, यह परीक्षण परीक्षण है ।

विचार कोड के टुकड़ों को बदलने, उन पर परीक्षण चलाने और यदि परीक्षण नहीं गिरते हैं, तो वे अपूर्ण हैं।

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


स्रोत कोड में उत्परिवर्तन लागू करने के परिणामस्वरूप, यह उत्परिवर्तित हो जाता है और एक उत्परिवर्ती बन जाता है।

उत्परिवर्ती दो श्रेणियों में विभाजित हैं:

1. मारे गए - वे जिनमें हम विचलन की पहचान करने में सक्षम थे, जिस पर कम से कम एक परीक्षण गिर गया।
2. जो बचे हैं, वे हमसे दूर भागते हैं और बग को उत्पादन में लाते हैं।

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

यह थोड़ा सिद्धांत था, और अब इस पर विचार करें कि इसका उपयोग जावास्क्रिप्ट में कैसे किया जा सकता है।

जावास्क्रिप्ट समाधान

जावास्क्रिप्ट में केवल एक सक्रिय रूप से विकसित म्यूटेशन टेस्टिंग टूल है - स्ट्राइकर । यह नाम एक्स-मैन विलियम स्ट्राइकर के चरित्र के सम्मान में साधन को दिया गया था - "वेपन एक्स" के निर्माता और सभी म्यूटेंट के साथ एक लड़ाकू।



स्ट्राइकर कर्म या जेस्ट की तरह एक परीक्षण धावक नहीं है; न ही यह मोचा या जैस्मीन की तरह एक परीक्षण रूपरेखा है। यह एक म्यूटेशन टेस्टिंग फ्रेमवर्क है जो आपके मौजूदा बुनियादी ढांचे को पूरक बनाता है।

प्लगइन प्रणाली

स्ट्राइकर बहुत लचीला है, पूरी तरह से प्लग-इन सिस्टम पर बनाया गया है, जिसमें से अधिकांश स्ट्राइकर डेवलपर्स द्वारा लिखे गए हैं।


जेस्ट, कर्मा और मोचा पर परीक्षण चलाने के लिए प्लगइन्स हैं। मोचा (स्ट्राइकर-मोचा-फ्रेमवर्क) जैस्मीन (स्ट्राइकर-जैस्मीन) और जावास्क्रिप्ट, टाइपस्क्रिप्ट और यहां तक ​​कि वीयू के लिए तैयार म्यूटेटर सेट के साथ एकीकरण है।

• स्ट्राइकर-जावास्क्रिप्ट-mutator;
• स्ट्राइकर-टाइपप्रति;
• स्ट्राइकर-Vue-mutator।

प्रतिक्रिया के लिए म्यूटेटर स्ट्राइकर-जावास्क्रिप्ट-म्यूटेटर में शामिल हैं। इसके अतिरिक्त, आप हमेशा अपने स्वयं के उत्परिवर्ती लिख सकते हैं।

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


यह सब अपेक्षाकृत सरल रूप से स्थापित किया गया है।

विन्यास

कॉन्फ़िगर करना मुश्किल नहीं है: आपको केवल JSON कॉन्फिगरेशन में निर्दिष्ट करने की आवश्यकता है जो आपके द्वारा उपयोग किए जाने वाले रनर (और / या टेस्ट फ्रेमवर्क और / या ट्रांसपिलर) का परीक्षण करते हैं, साथ ही साथ npm से उपयुक्त प्लगइन्स भी इंस्टॉल करते हैं।

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

यह कैसे काम करता है

जीवन चक्र सरल है और इसमें निम्नलिखित चरण हैं:

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

ऊपर स्ट्रीकर शुरू करने का एक उदाहरण है:

• स्ट्राइकर शुरू होता है;
• एक विन्यास पढ़ता है;
• आवश्यक निर्भरता लोड करता है;
• फ़ाइलों को म्यूट करेगा;
• स्रोत कोड पर परीक्षण चलाता है;
• 152 म्यूटेंट बनाता है;
• 8 थ्रेड्स में परीक्षण चलाता है (इस मामले में, सीपीयू कोर की संख्या के आधार पर)।

यह एक त्वरित प्रक्रिया नहीं है, इसलिए इसे कुछ CI / CD सर्वर पर करना बेहतर है।

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

ये ऐसी संभावित समस्याएं हैं जो हमारे परीक्षणों में नहीं देखी गई थीं।

संक्षेप में देना

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

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

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