PHP में उत्परिवर्तन परीक्षण: कोड कवरेज के लिए एक गुणात्मक माप

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

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

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

उत्परिवर्तन परीक्षण क्या है

यह समझाने के लिए कि मेरा क्या मतलब है, मैं आपको कुछ उदाहरण दिखाऊंगा। वे सरल हैं, स्थानों में अतिरंजित हैं और स्पष्ट लग सकते हैं (हालांकि वास्तविक उदाहरण आमतौर पर काफी जटिल हैं और उनकी आंखों से नहीं देखा जा सकता है)।

स्थिति पर विचार करें: हमारे पास एक प्रारंभिक कार्य है जो एक वयस्क होने का दावा करता है, और एक परीक्षण है जो इसका परीक्षण करता है। परीक्षण में एक डेटाप्रॉइडर है, अर्थात यह दो मामलों का परीक्षण करता है: आयु 17 वर्ष और आयु 19 वर्ष। मुझे लगता है कि आपमें से कई के लिए यह स्पष्ट है कि Adult के पास 100% कवरेज है। एकमात्र रेखा। यह एक परीक्षण द्वारा किया जाता है। सब कुछ अद्भुत है।



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

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



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

ये दो उदाहरण हमें बताते हैं कि उत्परिवर्तन परीक्षण क्या है।

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

यदि परीक्षण हमें कुछ भी नहीं दिखाते हैं, यदि वे गिरते नहीं हैं, तो वे संभवतः पर्याप्त प्रभावी नहीं हैं। वे सीमा मामलों का परीक्षण नहीं करते हैं, जिनमें दावे नहीं होते हैं: शायद उन्हें सुधारने की आवश्यकता है। यदि परीक्षण गिरते हैं, तो वे शांत हैं। वे वास्तव में ऐसे परिवर्तनों से रक्षा करते हैं। इसलिए, हमारे कोड को तोड़ना कठिन है।

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

एक उत्परिवर्ती एक एकल कोड परिवर्तन है। यही है, हम एक निश्चित फ़ंक्शन लेते हैं जहां तुलना में एक> संकेत था, अगर, हम इस संकेत को> = - में बदलते हैं और हमें एक उत्परिवर्ती मिलता है। उसके बाद, हम परीक्षण चलाते हैं। यहाँ एक उत्परिवर्तन का उदाहरण दिया गया है (हमने प्रतिस्थापित> के साथ> =):



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

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

उसके बाद, हम परिणाम का मूल्यांकन करते हैं। टेस्ट गिर गए - फिर सब ठीक है। यदि वे गिर नहीं गए, तो वे बहुत प्रभावी नहीं हैं।

मैट्रिक्स

म्यूटेशन परीक्षण हमें क्या मैट्रिक्स देता है? यह तीन और कोड कवरेज को जोड़ता है, जिसके बारे में हम अभी बात करेंगे।

लेकिन पहले, चलो शब्दावली का विश्लेषण करते हैं।



मारे गए म्यूटेंट की अवधारणा है: ये ऐसे म्यूटेंट हैं जो हमारे परीक्षण "नेस्टेड" हैं (यानी, उन्होंने उन्हें पकड़ा)।



बची हुई उत्परिवर्ती (जीवित म्यूटेंट) की अवधारणा है। ये ऐसे म्यूटेंट हैं जो सजा से बचने में कामयाब रहे (यानी परीक्षण उन्हें नहीं पकड़ पाए)।



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

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

दूसरा संकेतक म्यूटेशन कोड कवरेज है। यह केवल गुणात्मक है, मात्रात्मक नहीं है, क्योंकि यह दर्शाता है कि आप कितने व्यावसायिक तर्क तोड़ सकते हैं और इसे नियमित रूप से कर सकते हैं, हमारे परीक्षण पकड़े जाते हैं।

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

उत्परिवर्तन परीक्षण के मुद्दे

आधे से कम प्रोग्रामर्स ने इस टूल के बारे में क्यों सुना? इसका उपयोग हर जगह क्यों नहीं किया जाता है?

कम गति

पहली समस्या (मुख्य में से एक) उत्परिवर्तन परीक्षण की गति है। कोड में, यदि हमारे पास दर्जनों म्यूटेशन ऑपरेटर हैं, यहां तक ​​कि सबसे सरल वर्ग के लिए भी, हम सैकड़ों उत्परिवर्तन उत्पन्न कर सकते हैं। प्रत्येक म्यूटेशन के लिए, आपको परीक्षण चलाने की आवश्यकता होगी। अगर हमारे पास कहना है, 5,000 यूनिट परीक्षण जो दस मिनट तक चलते हैं, तो म्यूटेशनल परीक्षण में घंटों लग सकते हैं।

इसे समतल करने के लिए क्या किया जा सकता है? कई थ्रेड्स में समानांतर में परीक्षण चलाएं। कई कारों में धाराएं फेंकी। यह काम करता है।

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

अगली चीज जो आप कर सकते हैं वह है म्यूटेशन ट्यूनिंग। चूंकि म्यूटेशन ऑपरेटरों को बदला जा सकता है, आप कुछ नियम निर्धारित कर सकते हैं जिनके द्वारा वे काम करते हैं, फिर आप कुछ उत्परिवर्तन को रोक सकते हैं यदि वे जानबूझकर समस्याओं को जन्म देते हैं।

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

अंतहीन म्यूटेंट

दूसरी समस्या जो उत्परिवर्तन परीक्षणों से उत्पन्न हो सकती है, वह तथाकथित अंतहीन म्यूटेंट है। उदाहरण के लिए, सरल कोड है, लूप के लिए एक सरल:



यदि आप i ++ को i-- से प्रतिस्थापित करते हैं, तो चक्र एक अनंत में बदल जाएगा। आपका कोड लंबे समय तक रहेगा। और उत्परिवर्तन परीक्षण काफी बार ऐसे उत्परिवर्तन उत्पन्न करता है।

पहली चीज जो आप कर सकते हैं वह है म्यूटेशन ट्यूनिंग। जाहिर है, i ++ को i - for - for लूप में बदलना एक बहुत बुरा विचार है: 99% मामलों में हम एक अनंत लूप के साथ समाप्त हो जाएंगे। इसलिए, हमने अपने टूल में ऐसा करने से मना किया है।

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

पहचान के म्यूटेंट

यह समस्या उत्परिवर्तन परीक्षण के सिद्धांत में मौजूद है। व्यवहार में, वे इसका सामना अक्सर नहीं करते हैं, लेकिन आपको इसके बारे में जानने की आवश्यकता है।

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

कोई सार्वभौमिक समाधान नहीं है - हर कोई इस समस्या को अपने तरीके से हल करता है। शायद कुछ प्रकार के उत्परिवर्ती पंजीकरण प्रणाली से मदद मिलेगी। हम बुश में कुछ इसी तरह के बारे में सोच रहे हैं, हम उनकी नकल करेंगे।

यह एक सिद्धांत है। PHP के बारे में क्या?

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

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

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

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

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

हम इसका उपयोग कैसे करते हैं?

पहला मैनुअल रन है। यह पहली बात है। आपके द्वारा लिखे गए सभी परीक्षण म्यूटेशन परीक्षण द्वारा मैन्युअल रूप से सत्यापित किए जाते हैं। यह कुछ इस तरह दिखता है:



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

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

दूसरी चीज जिसका हम उपयोग करते हैं वह है मास्टर पर रिपोर्ट। दिन में एक बार, रात में, जब हमारा विकास का आधारभूत ढांचा निष्क्रिय होता है, हम एक कोड कवरेज रिपोर्ट तैयार करते हैं। उसके बाद, हम एक ही उत्परिवर्तन परीक्षण रिपोर्ट बनाते हैं। यह इस तरह दिखता है:



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

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



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

परिणाम

किसी भी संख्या को देना अभी भी मुश्किल है: हमारे पास कोई संकेतक नहीं था, अब यह दिखाई दिया है, लेकिन इसकी तुलना करने के लिए कुछ भी नहीं है।

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

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

निष्कर्ष

कोड कवरेज एक महत्वपूर्ण मीट्रिक है जिसकी निगरानी करने की आवश्यकता है। लेकिन यह संकेतक कुछ भी गारंटी नहीं देता है: इसका मतलब यह नहीं है कि आप सुरक्षित हैं।

उत्परिवर्तन परीक्षण आपकी इकाई परीक्षणों को बेहतर बनाने में मदद कर सकता है और कोड कवरेज पर नज़र रखना समझ में आता है। PHP के लिए पहले से ही एक उपकरण है, इसलिए यदि आपके पास बिना किसी परेशानी के एक छोटा प्रोजेक्ट है, तो आज ही पकड़ें और कोशिश करें।

कम से कम एक उत्परिवर्तन परीक्षण को मैन्युअल रूप से चलाकर प्रारंभ करें। यह सरल कदम उठाएं और देखें कि यह आपको क्या देता है। मुझे यकीन है कि आप इसे पसंद करेंगे