2009-09-14 12 views
15

में सारांश आवश्यक है क्योंकि यूनिट टेस्ट विधि का नामकरण इसके उद्देश्य को और अधिक सार्थक बनाता है, क्या यूनिट टेस्ट विधि में सारांश जोड़ना आवश्यक है?यूनिट टेस्ट विधि

उदाहरण:

/// <summary> 
/// Check the FormatException should be thrown when a give country data line contains a invalid number. 
/// </summary> 
[TestMethod] 
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber() 
{ 
    ... 
} 
+0

कोई और स्कीट जवाब अजीब रूप से देखता है तो उसे तुरंत बाद में हटा दें? – Will

+0

@Will - हाँ मैंने यह भी देखा। –

+0

@ विल- क्या इससे कोई फर्क पड़ता है? – RichardOD

उत्तर

9

मुझे लगता है कि लंबे वर्णनात्मक नाम XML टिप्पणी से अधिक महत्वपूर्ण है। चूंकि यूनिट टेस्ट एपीआई का हिस्सा नहीं बन रहा है, इसलिए आपको एक्सएमएल टिप्पणी की आवश्यकता नहीं है।

उदाहरण के लिए:

///<summary> 
/// Exception Should Thrown When Parse CountryLine Containing InvalidNumber 
///</summary> 
[TestMethod] 
public void Test42() 
{ 
    ... 
} 

एक्सएमएल टिप्पणियाँ एपीआई और चौखटे के दस्तावेजीकरण के लिए इस्तेमाल किया जाना चाहिए:

[TestMethod] 
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber() 
{ 
    ... 
} 

की तुलना में अधिक उपयोगी है।

+0

मेरे द्वारा +1। इसके अलावा मैंने यूनिट परीक्षणों से दस्तावेज कभी नहीं देखा है। यदि कोड अच्छी तरह से लिखा गया है तो यह स्वयं वर्णन करना चाहिए। यह सामान्य है यदि आप मिश्रित विधियों का उपयोग करते हैं- http://c2.com/ppr/wiki/WikiPagesAboutRefactoring/ComposedMethod.html – RichardOD

0

नहीं आवश्यक है, लेकिन अगर आप XML टिप्पणियाँ ऊपर और इकाई परीक्षण ही (जो व्यापक होने की तरह दिखता है) के नाम से परे मूल्य जोड़ने लग रहा है तो आप अन्य करने जा रहे हैं डेवलपर्स एक सेवा।

यदि सारांश अनिवार्य रूप से इकाई परीक्षण विधि नाम का प्रत्यक्ष डुप्लिकेट है, तो मुझे लगता है कि यह अधिक है।

1

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

-1

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

0

उपर्युक्त उदाहरण के लिए, मैं कहूंगा कि यह आवश्यक नहीं है, जब तक कि आप उस उपकरण का उपयोग न करें जो स्रोत से दस्तावेज निकालता है (जैसे जावाडोक या कुछ)।

अंगूठे का एक आम नियम यह है कि कोड कहता है कि आप क्या कर रहे हैं और टिप्पणी कहती है, लेकिन चूंकि नाम इतना वर्बोज़ है (जो मुझे लगता है ठीक है, क्योंकि किसी को भी इसे टाइप करना नहीं है) ऐसा मत सोचो कि टिप्पणी कुछ भी योगदान देती है।

0

सारांश सारांश जोड़ना आवश्यक है जब सारांश अधिक जानकारी प्रदान कर सकता है जिसे विधि नाम में एन्कोड किया जा सकता है। कृपया ध्यान दें कि जब मैं किसी भी दस्तावेज़ीकरण का जिक्र करते समय "जरूरी" कहता हूं, तो मेरा मतलब है कि "परियोजना को विरासत में रखने वाले नए कोडर के लिए आवश्यक संदर्भ/विवरण/बारीकियों के 100% को व्यक्त करना आवश्यक है या 5 साल बाद खुद को"।

37

मैं वास्तव में सारांश टैग पर विवरण एट्रिब्यूट का उपयोग करना पसंद करता हूं। कारण यह है कि विवरण विशेषता का मान परिणाम फ़ाइल में दिखाई देगा। यह समझना महत्वपूर्ण है जब तुम सिर्फ एक लॉग फ़ाइल

[TestMethod,Description("Ensure feature X doesn't regress Y")] 
public void TestFeatureX42() { 
    .. 
} 
+0

यह परीक्षण सूची में दिखाता है जो सहायक हो सकता है। – Will

+0

+1। हाँ यह एक अच्छा विचार की तरह लगता है। – RichardOD

+0

+1 भी मुझसे। परीक्षण परियोजनाओं सहित सभी परियोजनाओं के लिए तरीकों के लिए नामकरण सम्मेलन रखा जाना चाहिए - ऐसे डेटा को रखने के लिए डिज़ाइन किए गए स्थानों के बजाय विधि के नाम में सार या विवरण डालने का क्या कारण है? – Spook

0

एक एक्सएमएल टिप्पणी पर है पूरी तरह से अनावश्यक यदि आप एक वर्णनात्मक विधि नाम है देख रहे हैं विफलताओं आसान बना देता है। और यह यूनिट-टेस्ट विधियों के लिए जरूरी है।

आप पहले से ही एक वर्णनात्मक परीक्षण विधि नाम वाले सही ट्रैक पर हैं। (कई चुस्त और टीडीडी चिकित्सकों का मानना ​​है कि एक परीक्षण विधि में "चाहिए" शामिल होना चाहिए, उदाहरण के लिए इस ब्लॉग पोस्ट में link text में दिखाया गया है।

MyClass_OnInvalidInput_ShouldThrowFormatException() 

लेकिन वह केवल मेरी निजी पसंद है:

व्यक्तिगत रूप से, मैं इस तरह विधि के नाम की तरह।

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