2008-09-09 5 views
70

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

उत्तर

89

InternalsVisibleTo बचाव के लिए विशेषता!

बस जोड़ें:

[assembly:InternalsVisibleToAttribute("UnitTestAssemblyName")] 

अपने कोर कक्षाएं AssemblyInfo.cs फ़ाइल

सर्वोत्तम प्रथाओं के लिए Friend Assemblies (C# Programming Guide) देखें।

+3

मैंने एकू लिंक के मार्गदर्शन के बाद इसे एक मजबूत नामित असेंबली के साथ सफलतापूर्वक किया। हालांकि मेरे पास एक मुद्दा था। सबकुछ कॉन्फ़िगर करने के बाद मुझे इंटेलिजेंस के लिए काम करने के लिए विजुअल स्टूडियो को पुनरारंभ करना पड़ा। यह पुनरारंभ करने से पहले संकलित होगा लेकिन हमेशा लाल रेखाएं दिखाएगा। –

2

आप प्रतिबिंब (एमएस टेस्ट आइटम के रूप में) का उपयोग कर सकते हैं, या आप यूनिट टेस्ट असेंबली को मूल असेंबली के मित्र घोषित कर सकते हैं।

दूसरा विकल्प यूनिट परीक्षणों को एक ही असेंबली में रखना है।

20
InternalsVisible साथ

अपने विधानसभाओं दृढ़ता से नाम हैं अगर आप सार्वजनिक कुंजी निर्दिष्ट करने की आवश्यकता (ध्यान दें: पूर्ण कुंजी नहीं सार्वजनिक कुंजी टोकन) उदाहरण के लिए ...

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("BoardEx_BusinessObjects.Tests, 
    PublicKey=0024000004800000940000000602000000240000525341310004000001000100fb3a2d8 etc etc")] 

और निम्न चाल है cmd लाइन का सहारा के बिना सार्वजनिक कुंजी प्राप्त करने के लिए वास्तव में उपयोगी ...

http://www.andrewconnell.com/blog/archive/2006/09/15/4587.aspx

+0

संदर्भ लिंक अब दुर्भाग्य से काम नहीं करता है। – toong

+0

धन्यवाद @toong मैंने इसे अपडेट किया है। –

2

मैं ऐसे मुसीबतों ... यदि आप वास्तव में इकाई ट करना चाहते हैं नहीं जा रहा सुझाव है अपने "आंतरिक" वर्गों को, बस उन्हें एक नामस्थान में छिपाएं कि केवल आपका आंतरिक कोड उपयोग समाप्त हो जाएगा। जब तक आप .NET ढांचे के पैमाने पर एक ढांचा लिख ​​रहे हों, तो आप वास्तव में छिपाने के स्तर की आवश्यकता नहीं है।

+0

मैं बिल्कुल टिप्पणी करने जा रहा था जब मैंने नीचे आपकी टिप्पणी देखी थी। +1! :) –

9

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

मैंने इस दृष्टिकोण पर कुछ आपत्तियां सुनी हैं, लेकिन उनमें से कुछ विश्वासयोग्य हैं।

यह प्रदर्शन बहता है, मैं कहता हूं! हार्ड डेटा के बिना अनुकूलन मत करो! शायद यदि आप धीमे लिंक पर डाउनलोड करने के लिए अपनी असेंबली की योजना बना रहे हैं, तो असेंबली आकार को कम करना सार्थक होगा।

यह एक सुरक्षा जोखिम है। केवल अगर आपके पास अपने परीक्षणों में रहस्य हैं। ऐसा मत करो।

अब, आपकी स्थिति मेरे से अलग है, तो हो सकता है कि यह आपके लिए समझ में आए, और शायद यह नहीं होगा। आपको खुद को समझना होगा।

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

+5

दिलचस्प दृष्टिकोण। और मैं पूरी तरह से परीक्षण होने के बारे में सहमत हूं। बेवकूफ आवश्यकता, आईएमओ। – Kilhoffer

+0

@ किलहोफर: मैं इसके बारे में वर्षों से शिकायत कर रहा हूं, और आप वास्तव में मुझसे सहमत होने वाले पहले व्यक्ति हैं। धन्यवाद! –

+6

यदि आप परीक्षण कक्षाओं पर '[सशर्त (" DEBUG ")]' का उपयोग करते हैं तो उन्हें उत्पादन असेंबली में नहीं होना चाहिए और प्रदर्शन को चोट नहीं पहुंचाया जाना चाहिए। – xmedeko

संबंधित मुद्दे