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

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

यह था:

if(somevalue < threshold) { doSomething(); }

यह बन गया:

if(somevalue >= threshold) { doSomething(); }

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

सरल परियोजना

आइए एक एकल वर्ग के साथ एक सरल ^{[ गिटब ]} परियोजना के साथ शुरू करें:

1 2 3 4 5 6 8

public class ClassToTest { private static final double THRESHOLD = 10.0; public static boolean threshold(double value) { return value >= THRESHOLD; } }

और इसके लिए परीक्षण करें:

1 2 3 4 5

@Test public void testThreshold() { Assert.assertTrue(ClassToTest.threshold(10.0)); Assert.assertFalse(ClassToTest.threshold(9.0)); }

पिटारेस्ट को जोड़ने के लिए, बस इसके प्लगइन को मावेन में जोड़ें:

1 2 3 4 5 6 7 8 9 10 11 12 13

<plugin> <groupId>org.pitest</groupId> <artifactId>pitest-maven</artifactId> <version>0.25</version> <configuration> <inScopeClasses> <param>com.example*</param> </inScopeClasses> <targetClasses> <param>com.example*</param> </targetClasses> </configuration> </plugin>

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

यदि किसी कारण से आप मावेन का उपयोग नहीं कर रहे हैं, तो सब कुछ नहीं चला गया है: आप इसे कमांड लाइन से उपयोग कर सकते हैं, मैनुअल यहां उपलब्ध है ।

और मावेन का उपयोग करके खुशी पाने के लिए, बस कमांड चलाएं:

mvn org.pitest:pitest-maven:mutationCoverage

रिपोर्ट को समझना

चेक के परिणामस्वरूप, हमें लॉग की एक बड़ी शीट मिलती है। इसे पढ़ना विशेष रूप से सुविधाजनक नहीं है, लेकिन target/pit-reports/%TIMESTAMP% फ़ोल्डर में कोड कवरेज के समान एक HTML रिपोर्ट भी उत्पन्न होती है। हमारे मामले में, इसका दिलचस्प हिस्सा कुछ इस तरह दिखाई देगा:



यहां लाइन 14 के पास नंबर तीन का मतलब है कि इस लाइन में कितने म्यूटेशन लगाए गए हैं। नीचे दिए गए उत्परिवर्तन खंड प्रत्येक पंक्ति के लिए वर्णन करते हैं कि कौन से उत्परिवर्तन लागू किए गए थे और परिणाम क्या था।

उत्परिवर्तन का परिणाम

• KILLED - एक उत्परिवर्तन के परिणामस्वरूप, इस स्ट्रिंग की जाँच करने वाले सभी परीक्षण गिर गए। आप देख सकते हैं कि हमारे देश में सभी उत्परिवर्तनों में ऐसी स्थिति है, जो बहुत अच्छी है।
• सर्वेक्षण - म्यूटेशन पर किसी का ध्यान नहीं गया। इसका मतलब है कि कार्यक्षमता में परिवर्तन परीक्षणों द्वारा कवर नहीं किया गया है।
• TIMED_OUT - परीक्षण ने बहुत लंबे समय तक काम किया (उदाहरण के लिए, एक अनंत लूप के परिणामस्वरूप)
• NON_VIABLE - उत्परिवर्तन से उत्पन्न बल्ला कोड किसी कारण से अमान्य हो गया (यह बहुत कम ही होता है)
• MEMORY_ERROR - उत्परिवर्तन के परिणामस्वरूप, कोड बहुत अधिक मेमोरी का उपभोग करने लगा और OOM से गिर गया
• RUN_ERROR - उत्परिवर्तन के परिणामस्वरूप, एक कोड उत्पन्न होता है जो एक अपवाद को फेंकता है

म्यूटेशन के प्रकार

फिलहाल, केवल 11 म्यूटेशन हैं। हरे रंग में हाइलाइट किए गए वे डिफ़ॉल्ट रूप से सक्षम हैं।

• CONDITIONALS_BOUNDARY - चेक में सख्त असमानताओं को गैर-सख्त और इसके विपरीत में बदल दिया जाता है। उदाहरण के लिए, <= में बदल जाता है
• NEGATE_CONDITIONALS - स्थितियों को प्रभावित करता है। उदाहरण के लिए, == में बदल जाएगा !=
• MATH - प्रयुक्त गणितीय ऑपरेटरों को प्रतिस्थापित करता है। उदाहरण के लिए, यह माइनस को प्लस में बदलता है।
• सामग्री - वेतन वृद्धि और इसके विपरीत के साथ वेतन वृद्धि को प्रतिस्थापित करता है
• INVERT_NEGS - पूर्णांकों और वास्तविक संख्याओं के संकेत को सम्मिलित करता है
• INLINE_CONSTS - अपनी जगह में एक अलग मूल्य प्रतिस्थापित करते हुए, शाब्दिक परिवर्तन करता है। उदाहरण के लिए, 42 को 43 लिए प्रतिस्थापित किया जाएगा, और false को true लिए प्रतिस्थापित किया जाएगा true
• RETURN_VALS - विधि द्वारा दिए गए मान को कुछ अन्य के साथ बदल देता है । उदाहरण के लिए, एक पूर्ण वस्तु के बजाय, अशक्त वापस कर दिया जाएगा।
• VOID_METHOD_CALLS - शून्य विधि कॉल को हटाता है
• NON_VOID_METHOD_CALLS - गैर-शून्य विधियों को कॉल करने के बजाय, इस विधि के प्रकार के लिए डिफ़ॉल्ट मान लौटाता है ( false , 0 , null )
• CONSTRUCTOR_CALLS - कंस्ट्रक्टर को कॉल करने के बजाय नल का उपयोग करता है
• EXPERIMENTAL_INLINE_CONSTS - INLINE_CONSTS के समान, लेकिन कुछ हद तक अधिक स्मार्ट

विभिन्न प्रकार के उत्परिवर्तन का विस्तृत विवरण आधिकारिक वेबसाइट पर उपलब्ध है।

एक उदाहरण की शिकायत करना

यह पता चला है कि हमारे नमूना परियोजना में म्यूटेशन की स्थिति (2 पीसी) और वापसी मूल्य में थे। अब अधिक उत्परिवर्तन को प्राप्त करने का प्रयास करते हैं। हम इस तरह से कक्षा को फिर से लिखते हैं:

1 2 3 4 5 6 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public class ClassToTest { private int invocationCount = 0; private static final double OFFSET = 1.0; private final double threshold; public ClassToTest(double threshold) { this.threshold = threshold; } public boolean threshold(double value) { logInvocation(); return value >= threshold + OFFSET; } private void logInvocation() { invocationCount++; } }

लेकिन परीक्षणों में हम नई कार्यक्षमता का परीक्षण नहीं करेंगे:

1 2 3 4 5 6 7

@Test public void testThreshold() { ClassToTest classToTest = new ClassToTest(10.0); Assert.assertTrue(classToTest.threshold(11.0)); Assert.assertFalse(classToTest.threshold(10.0)); }

कोड कवरेज चलाते समय, किसी भी समस्या का पता नहीं लगाया जाएगा। लेकिन अगर हम उत्परिवर्तन परीक्षण चलाते हैं, तो वे जल्दी से हमें हाथ से पकड़ लेंगे और कहेंगे: लेकिन कार्यक्षमता का परीक्षण नहीं किया गया है!



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

क्यों वास्तव में बहुत बुरा?

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

एक वास्तविक परियोजना पर जाँच करें

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

कोबेरुरा दिखाता है कि सब कुछ ठीक है:

पिटारे में आंसू होते हैं:

कुल मिलाकर

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

आपके प्रश्नों, टिप्पणियों और टिप्पणियों में सुधार की प्रतीक्षा है!