.NET में गैर-सार्वजनिक तरीकों का परीक्षण कैसे करें

क्या आप परीक्षणों के साथ कोड को कवर करना पसंद करते हैं? क्या आपको सुरक्षा का अच्छा गर्म एहसास पसंद है जो परीक्षण के साथ आता है?



शाबाश!



असली पेशेवर मामले पर भरोसा नहीं करते हैं, वे सब कुछ नियंत्रण में रखने के लिए अग्रिम में पुआल बिछाते हैं ।



क्या आप चाहते हैं कि सब कुछ सार्वजनिक इंटरफ़ेस के पीछे, परीक्षणों से ढंका जाए?







हमेशा की तरह, कई तरीके हैं। वहाँ बेहतर है, वहाँ आसान है। चलो चलते हैं!

1. विधि को सार्वजनिक करना

कोई निजी तरीका नहीं - कोई समस्या नहीं। आप विधि पर एक टिप्पणी भी लिख सकते हैं

// For tests only. Do not use directly.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

पेशेवरों: बहुत आसान है।

विपक्ष: इंटरफ़ेस भरा हुआ है, एनकैप्सुलेशन ग्रस्त है।

2. विधि को आंतरिक बनाना

यही है, हम private



से internal



तक पहुंच संशोधक को बदलते हैं। पहली विधि से टिप्पणी यहाँ भी करेंगे। यह एक ऐसी विधि को बताता है जो विधानसभा के भीतर कहीं से भी सुलभ है।



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



यह मत भूलो कि InternalsVisibleTo



विशेषता के कामकाज के लिए, यह आवश्यक है कि दोनों विधानसभाओं (परीक्षण और परीक्षण) को एक ही समय में एक मजबूत नाम के साथ हस्ताक्षरित किया जाए, या एक ही समय में हस्ताक्षर नहीं किया जाए।



पेशेवरों: काफी सरल है, वहाँ नियंत्रण रहता है, जिसके पास विधानसभा के अंदरूनी हिस्सों तक पहुंच है।

विपक्ष: इंटरफ़ेस अभी भी भरा हुआ है, एनकैप्सुलेशन अभी भी ग्रस्त है, अतिरिक्त स्थितियां दिखाई देती हैं (हस्ताक्षर करने के लिए ऊपर देखें), विशेषता रिलीज़ असेंबली में बनी हुई है।

3. विधि को सुरक्षित बनाना

private



संशोधक के बजाय, विधि को protected



संशोधक का अधिग्रहण करना चाहिए। परीक्षण असेंबली में, आपको परीक्षण किए गए वर्ग और - वॉइला से एक वारिस बनाने की आवश्यकता होगी! - प्राप्त विधि तक पहुंच।



पेशेवरों: काफी सरल है, विधि पर पहुंच रखने वालों पर कुछ नियंत्रण है।

विपक्ष: इंटरफ़ेस वैसे भी बंद हो जाता है, एनकैप्सुलेशन वैसे भी ग्रस्त है, यह विधि किसी भी व्यक्ति के लिए सुलभ है जो इसे विरासत में लेना चाहता है, इस पद्धति के साथ एक वर्ग को सील के रूप में चिह्नित नहीं किया जा सकता है।

4. PrivateObject का उपयोग करना

यह वर्ग विजुअल स्टूडियो यूनिट टेस्टिंग फ्रेमवर्क प्रदान करता है, इसलिए यदि परियोजना NUnit या कुछ और का उपयोग करती है, तो यह विधि काम नहीं करेगी।



PrivateObject



साथ PrivateObject



सब कुछ सरल है। परीक्षण के लिए एक वर्ग है:

 public class ClassToTest { private string field; private void PrintField() { Console.WriteLine(field); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

एक परीक्षण वर्ग है:

 [TestClass] public class TestClass { [TestMethod] public void TestPrivateMethod() { ClassToTest testedClass = new ClassToTest(); PrivateObject privateObject = new PrivateObject(testedClass); privateObject.SetField("field", "Don't panic"); privateObject.Invoke("PrintField"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

परीक्षण पूरा होने के बाद, कंसोल लाइन देखेगा Don't panic



। हमेशा अच्छी सलाह, सही?



पेशेवरों: मौजूदा कोड को बदलने की आवश्यकता नहीं है, सरल पर्याप्त।

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

5. प्रतिबिंब हमारी मदद करेगा

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



फिर से, परीक्षण के लिए एक वर्ग है:

 public class ClassToTest { private string field; private void PrintField() { Console.WriteLine(field); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

परीक्षण में आपको निम्नलिखित लिखने की आवश्यकता है:

 ClassToTest obj = new ClassToTest(); Type t = typeof(ClassToTest); FieldInfo f = t.GetField("field", BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public); f.SetValue(obj, "Don't panic"); t.InvokeMember("PrintField", BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance, null, obj, null);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

कंसोल में फिर से अच्छी सलाह दिखाई देनी चाहिए।



उपरोक्त कोड का उपयोग किसी भी परीक्षण में किया जा सकता है। कम से कम NUnit के लिए, कम से कम Visual Studio Unit टेस्टिंग फ्रेमवर्क के लिए, कम से कम किसी अन्य परीक्षण वातावरण के लिए।



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

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

एक निष्कर्ष के बजाय

अब जब आप जानते हैं कि गैर-सार्वजनिक तरीकों का परीक्षण कैसे किया जाता है, तो यह सोचने का समय है: क्या उन्हें परीक्षण करने की आवश्यकता है?



इसके लिए तर्क:

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

इसके विरुद्ध तर्क:

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

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