क्या यूनिट परीक्षण के लिए कोड जोड़ना बुरा है?

Question

मैं अपने कोड का परीक्षण करने में मेरी सहायता करने के लिए एक कक्षा लिख ​​रहा हूं। ऐसा लगता है:

/// <summary> 
/// Wrapper for the LogManager class to allow us to stub the logger 
/// </summary> 
public class Logger 
{ 
    private static ILogger _logger = null; 

    /// <summary> 
    /// This should be called to get a valid logger. 
    /// </summary> 
    /// <returns>A valid logger to log issues to file.</returns> 
    public static ILogger GetLogger() 
    { 
     if (_logger == null) 
      _logger = LogManager.GetLogger("logger"); 

     return _logger; 
    } 

    /// <summary> 
    /// This is used by unit tests to allow a stub to be used as a logger. 
    /// </summary> 
    /// <param name="logger"></param> 
    /// <returns></returns> 
    public static ILogger GetLogger(ILogger logger) 
    { 
     _logger = logger; 
     return _logger; 
    } 
} 

दूसरी विधि केवल यूनिट परीक्षण के लिए है। मैं कभी भी अपने उत्पादन कोड में इसे कॉल करने का इरादा नहीं रखता।

क्या यह बुरा अभ्यास है? क्या मुझे ऐसा कोई और तरीका मिलना चाहिए जो ऐसा नहीं करता?

Answer 1

आप इस पर विचार कर सकते:

/// <summary> 
/// Wrapper for the LogManager class to allow us to stub the logger 
/// </summary> 
public class Logger 
{ 
    private static ILogger _logger = null; 

    /// <summary> 
    /// This should be called to get a valid logger. 
    /// </summary> 
    /// <returns>A valid logger to log issues to file.</returns> 
    public static ILogger Logger 
    { 
     get 
     { 
      if (_logger == null) 
      { 
       _logger = LogManager.GetLogger("logger"); 
      } 
      return _logger 
     } 
     set 
     { 
      _logger = value; 
     } 
    } 
} 

यह लकड़हारा पहली बार यदि वह पहले से सेटर का उपयोग कर स्थापित नहीं किया गया गेटर कहा जाता है निर्धारित करता है।

Answer 2

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

Answer 3

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

Answer 4

मैं नहीं कहूंगा कि कोड का यह विशेष टुकड़ा समस्या है। जब तक आप अपने xmldoc टिप्पणियों में बताते हैं कि विधि (ओं) केवल यूनिट परीक्षण के लिए लक्षित है, नहीं (sane!) व्यक्ति इसे उत्पादन कोड में उपयोग करेगा।

हालांकि, जब भी संभव हो, ऐसी चीजों को अपनी इकाई परीक्षण पुस्तकालय में रखने का प्रयास करें। जैसा कि जोएल ईथरटन कहते हैं, यह किसी भी मामले में कोड ब्लोट है ...

Answer 5

आम तौर पर, कोड केवल इकाई परीक्षण hides a design flaw की सुविधा के लिए मौजूद है।

इस मामले में, आप जो छिपा रहे हैं वह global state का उपयोग है। आपके लॉगर का उपयोग करने वाले वर्ग गुप्त रूप से इस पर निर्भर हैं: आप यह नहीं बता सकते कि उन्हें लॉगर की आवश्यकता नहीं है जब तक कि आप उनका स्रोत कोड नहीं पढ़ते!

उन वर्गों उनके निर्माताओं में एक ILogger की आवश्यकता होती है चाहिए, यह स्पष्ट है कि वे क्या काम करते हैं और उनका परीक्षण करने के लिए आसान बनाने की जरूरत बन गया है।

Answer 6

आईएमओ, हाँ, यह खराब कोड है। दो कारण:

• लॉगर LogManager के बारे में जानता है। यह कसकर जोड़ों LogManager के लिए लॉगजर, और आप सामना की समस्या प्रस्तुत करता है; आपको ILMger ऑब्जेक्ट प्राप्त करने के लिए LogManager का उपयोग करना होगा, और LogManager को स्टब या नकल नहीं कर सकता है।
• आप इकाई परीक्षण करने के एकमात्र उद्देश्य के लिए एक उत्पादन वर्ग के लिए कोड जोड़ लिया है। इससे डेवलपर्स को सड़क पर भ्रमित कर दिया जाएगा, जो परीक्षण हुक देखते हैं और सोचते हैं कि वे इसे उत्पादन कोड में उपयोग कर सकते हैं।

मैं एक या निम्न में अधिक की सिफारिश करेंगे:

• एक अंतरफलक ILogManager कि GetLogger (उजागर) को परिभाषित करें, और LogManager पर इसे लागू।फिर, लॉगर प्रकार के ILogManager पर एक संपत्ति बनाएं (या लॉगर को चालू करते समय एक को पारित करने की आवश्यकता है) और लॉगर को लॉगजर के दायरे से बाहर लॉगऑनगर दें (एक आईओसी फ्रेमवर्क के माध्यम से, या जो भी लॉगर को तुरंत चालू करता है)। यह ढीला युग्मन है; अब आप किसी भी वर्ग की आपूर्ति कर सकते हैं जो MockLogManager सहित ILogManager लागू करता है, और लॉगर अंतर को नहीं जानता है।
• अपने यूनिट परीक्षण के प्रयोजनों के लिए, लॉगर से "प्रॉक्सी" प्राप्त करें और वहां किसी भी परीक्षण-केवल विधियों को लागू करें। मैं मुख्य रूप से कक्षा के यूनिट परीक्षण संरक्षित तरीकों के लिए इस विधि का उपयोग करता हूं, लेकिन यदि आप लॉगर से LogManager को रद्द करने में असमर्थ पाते हैं, तो आप कम से कम इस व्युत्पन्न प्रॉक्सी और अपने हुक को अपने परीक्षण असेंबली में छिपा सकते हैं, जहां उत्पादन कोड सक्षम नहीं होना चाहिए उन्हें संदर्भित करने के लिए।

Answer 7

हाँ, डिजाइन न सही :(GetLogger विधि वास्तव में लकड़हारा सेट है सेटर विधि का प्रयोग करें - इस अधिक उपयुक्त लग रहा है

BTW

, तुम क्या परीक्षण करते हैं आप नेट मानक वालों का उपयोग करते हैं।? - मजाक के लिए कॉन्फ़िगर apropriate लॉग श्रोताओं

और MOQ पुस्तकालय देखा है http://code.google.com/p/moq/ मुझे यह पसंद आया

Answer 8

- आप जोड़ सकते हैं या श्रोताओं को हटाना (जैसा कि मुझे याद है) और यदि आप कहीं कुछ लिखने के लिए परीक्षण की जरूरत नहीं है।?।

मेरे पास कोई अजीब रचनाकार नहीं है

private readonly ILog _log = LogManager.GetLogger(typeof(MyViewClassName)); 

कौन सा तो इस तरह के रूप में इस्तेमाल किया जा सकता है, इस मामले में यह कैच ब्लॉक के अंदर कहा जाता है::

_log.Error("SomePage.aspx.cs Page_Load failed", ex); 

वहाँ log4net के लिए कोई आवरण है EAD मैं दृश्य में एक निजी चर है। ILog log4net का हिस्सा है। मैं उत्सुक हूं कि आप मॉक्स का उपयोग क्यों नहीं कर रहे हैं। यह समझ में आता है और फिर आपको वह करने की ज़रूरत नहीं होगी जो आप कर रहे हैं।

Answer 9

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

इसे एक और तरीके से देखें; यदि आपके पास कुछ कोड बनाने के दो समान तरीके हैं, और मुख्य अंतर टेस्टेबिलिटी है, तो अधिक टेस्टेबल विकल्प के लिए जाएं।

लेकिन आपके कोड के विशिष्ट मामले के लिए, मैं यहां अन्य अधिकांश पोस्टों से सहमत हूं; उस कोड को लिखने का एक बेहतर तरीका है।

Answer 10

यहां क्या गलत है कि लॉगजर प्राप्त करने वाला कोड यह जानना है कि वह कौन सा लॉगर चाहता है। वास्तव में, इसकी देखभाल करने का कोई कारण नहीं है।

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

Answer 11

नहीं, यह बिल्कुल एक बुरी चीज नहीं है।

अच्छा कोड सभी आवश्यकताओं को पूरा करना चाहिए और कुछ और नहीं करना चाहिए।

हालांकि, आवश्यकताएं कई रूपों में आती हैं, और सभी कोडों की एक अस्थिर गैर-कार्यात्मक आवश्यकता यह है कि आप दूसरों को साबित कर सकते हैं कि यह काम करता है।

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

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