मेरे मालिक द्वारा मोक का उपयोग करने के लिए कहा गया और यह है। मुझे यह पसंद है लेकिन ऐसा लगता है कि एमएसटीएस्ट या एमबुनिट इत्यादि के विपरीत ... आप आंतरिक तरीकों का परीक्षण नहीं कर सकते हैंमोक आप आंतरिक तरीकों का परीक्षण कैसे करते हैं?
इसलिए मुझे अपने इंटरफ़ेस में कुछ आंतरिक कार्यान्वयन करने के लिए मजबूर होना पड़ता है ताकि मैं इसका परीक्षण कर सकूं।
क्या मुझे कुछ याद आ रही है?
क्या आप Moq का उपयोग करके आंतरिक विधियों का परीक्षण कर सकते हैं?
धन्यवाद एक बहुत
आप तरीकों Moq के लिए दृश्यमान बनाना InternalsVisibleTo विशेषता का उपयोग कर सकते हैं।
मजबूत नामित असेंबली के लिए, आपको इसकी आवश्यकता है। [विधानसभा: InternalsVisibleTo ("DynamicProxyGenAssembly2, PublicKey = 0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")] –
आप कई कोड है कि सार्वजनिक विधियों द्वारा परीक्षण नहीं किया है, तो आप शायद कोड है कि एक और वर्गों के लिए ले जाया जाना चाहिए है।
जैसा कि एक और उत्तर में कहा गया है, आप इसके लिए InternalsVisibleTo विशेषता का उपयोग कर सकते हैं। लेकिन इसका मतलब यह नहीं है कि आपको यह करना चाहिए।
इकाई परीक्षण की बात है, हालांकि सब कुछ परीक्षण करने के लिए नहीं है? आंतरिक/निजी तरीकों का परीक्षण करने से जनता के माध्यम से परीक्षण की समस्याएं प्रकट हो सकती हैं। विशेष रूप से नए सार्वजनिक कार्यों को जोड़ा जाता है और आंतरिक लोगों का उपयोग किया जाता है ... या क्या मुझे कुछ याद आ रही है? – CodeRedick
आपकी प्रारंभिक धारणा कि आंतरिक विधि का परीक्षण करना आवश्यक है, यूनिट परीक्षण के बारे में एक आम शुरुआत गलत धारणा है।
अनुमोदित, ऐसे मामले मौजूद हो सकते हैं जहां अलगाव में निजी तरीकों का परीक्षण किया जाना चाहिए, लेकिन 99% आम मामला यह है कि निजी तरीकों का परीक्षण किया जा रहा है क्योंकि वे सार्वजनिक तरीकों को अपने परीक्षण पास करते हैं। सार्वजनिक तरीकों से निजी तरीकों को बुलाया जाता है।
किसी कारण से निजी तरीके हैं। यदि वे बाह्य परीक्षण योग्य व्यवहार का नतीजा नहीं करते हैं, तो आपको उनकी आवश्यकता नहीं है।
क्या आपके सार्वजनिक परीक्षणों में से कोई भी विफल रहता है यदि आप उन्हें हटा देते हैं? यदि हां, तो वे पहले ही परीक्षण किए जा रहे हैं। यदि नहीं, तो आपको उनकी आवश्यकता क्यों है? पता लगाएं कि आपको उनके लिए क्या चाहिए और फिर सार्वजनिक इंटरफ़ेस के खिलाफ परीक्षण में व्यक्त करें।
टीडीडी के साथ एक मुख्य लाभ यह है कि आपका कोड बदलना आसान हो जाता है। यदि आप आंतरिक परीक्षण करना शुरू करते हैं, तो कोड कठोर और बदलना मुश्किल हो जाता है।
परीक्षण के लिए आंतरिक कक्षाओं को आंतरिक बनाने के साथ कुछ भी गलत नहीं है। यदि आपको कक्षा के आंतरिक परीक्षणों की जांच करने की ज़रूरत है, तो हर तरह से ऐसा करें। सिर्फ इसलिए कि विधियां सार्वजनिक नहीं हैं इसका मतलब यह नहीं है कि आपको उन्हें अनदेखा करना चाहिए और केवल जनता का परीक्षण करना चाहिए। एक अच्छी तरह से डिज़ाइन किए गए एप्लिकेशन में वास्तव में आपके वर्गों के भीतर कोड के बहुमत के रूप में इस तरह से होगा कि वे सार्वजनिक नहीं हैं। इसलिए आपके परीक्षण में गैर-सार्वजनिक तरीकों को अनदेखा करना आईएमएचओ की एक बड़ी गलती है। यूनिट परीक्षण की सुंदरियों में से एक यह है कि आप अपने कोड के सभी हिस्सों का परीक्षण करते हैं, भले ही आपका परीक्षण कितना छोटा हो और 100% पर चलने पर यह एक बहुत ही उचित धारणा है कि जब इन सभी भागों को एक साथ रखा जाता है, तो आपका आवेदन अंतिम उपयोगकर्ता के लिए ठीक से काम करेगा। बेशक यह सत्यापित करना कि बाद का हिस्सा वह है जहां एकीकरण स्तर के परीक्षण आते हैं - जो एक अलग चर्चा है। तो परीक्षण करें !!!
InternalsVisibleTo आंतरिक परीक्षण के लिए आपका मित्र है। अपनी असेंबली पर हस्ताक्षर करना याद रखें और आप सुरक्षित हैं।
मेरे दृष्टिकोण से मॉकिंग का उपयोग कुछ व्यवहारों को नकल करने के लिए किया जाना चाहिए जो हम निर्भर हैं लेकिन परीक्षण करने के लिए सेट नहीं कर रहे हैं। इसलिए:
प्रश्न: क्या मुझे कुछ याद आ रही है? - नहीं, आप कुछ भी नहीं खो रहे हैं, MOQ में निजी व्यवहारों का नकल करने की क्षमता गुम है।
प्रश्न: क्या आप Moq का उपयोग करके आंतरिक विधियों का परीक्षण कर सकते हैं? - यदि निजी व्यवहार का नतीजा सार्वजनिक रूप से दिखाई देता है, तो हाँ आप आंतरिक विधि का परीक्षण कर सकते हैं लेकिन यह मोक की वजह से नहीं है कि आप उनका परीक्षण कर सकते हैं। मैं यहां एक बिंदु बनाना चाहता हूं कि मॉक परीक्षण करने की क्षमता नहीं है बल्कि समान व्यवहार करने की क्षमता है जिसे हम परीक्षण नहीं कर रहे हैं लेकिन इस पर निर्भर करते हैं।
सी: टीडीडी के साथ एक मुख्य लाभ यह है कि आपका कोड बदलना आसान हो जाता है। यदि आप आंतरिक परीक्षण करना शुरू करते हैं, तो कोड बदलने के लिए कठोर और कठिन हो जाता है - मैं इस मुख्य टिप्पणी के लिए 2 मुख्य कारणों से सहमत नहीं हूं: 1: यह शुरुआती गलतफहमी नहीं है, क्योंकि टीडीडी कोड कोड करने की क्षमता के बारे में नहीं है तेज लेकिन बेहतर गुणवत्ता कोड भी। इसलिए अधिक परीक्षण हम बेहतर कर सकते हैं। 2: यदि आप आंतरिक तरीकों का परीक्षण कर सकते हैं तो यह कोड को और अधिक कठिन नहीं बना देता है।
मोक एमएसटीएस्ट या एमब्यूनिट का विकल्प नहीं है। वे यूनिट परीक्षण ढांचे दोनों हैं, जबकि मोक एक मॉकिंग फ्रेमवर्क है। हालांकि लगभग हमेशा संयोजन के रूप में प्रयोग किया जाता है, वे दो बहुत ही अलग चीजें हैं। बीटीडब्ल्यू +1 आपके मालिक को, मोक उत्कृष्ट है ;-) –