2010-03-01 22 views
8

मुझे आशा है कि यह एक बेवकूफ सवाल के रूप में नहीं आएगा, लेकिन इसकी कुछ चीज मैं सोच रहा हूं। मैं इकाई परीक्षण को एक विधि लिखना चाहता हूं जिसमें कुछ तर्क शामिल हैं कि कुछ मूल्य शून्य नहीं हैं।यूनिट परीक्षण - क्या मुझे परीक्षणों को विभाजित करना चाहिए या एक परीक्षण होना चाहिए?

public void MyMethod(string value1, string value2) 
{ 
    if(value1 != null) 
    { 
    //do something (throw exception) 
    } 

    if(value2 != null) 
    { 
    //do something (throw exception) 
    } 

    //rest of method 
} 

मैं विधि में शून्य मानों को पारित करके इसका परीक्षण करना चाहता हूं। मेरा सवाल है कि क्या मैं प्रत्येक तर्क के लिए एक यूनिट टेस्ट बनाना चाहता हूं या क्या मैं एक यूनिट टेस्ट बना सकता हूं जो जांचता है कि क्या होता है यदि मैं मान 1 को शून्य पर सेट करता हूं और फिर जांच करता है कि क्या होता है यदि मैं मान 2 को शून्य पर सेट करता हूं।

अर्थात

[TestMethod] 
public void TestMyMethodShouldThrowExceptionIfValue1IsNull() 
{ 
    //test 
} 

[TestMethod] 
public void TestMyMethodShouldThrowExceptionIfValue2IsNull() 
{ 
    //test 
} 

या

[TestMethod] 
public void TestMyMethodWithNullValues() 
{ 
    //pass null for value1 
    //check 

    //pass null for value2 
    //check 
} 

या यह कोई फर्क पड़ता है? मुझे लगता है कि मैंने कहीं पढ़ा है कि आपको प्रति यूनिट परीक्षण पर एक जोर देने के लिए खुद को सीमित करना चाहिए। क्या ये सही है?

अग्रिम zaps

+0

यह नियम नहीं है; यह एक निर्णय कॉल है। यदि परीक्षण स्पष्ट और पठनीय है, तो एक समारोह ठीक है। अन्यथा ** पठनीयता ** के लिए उन्हें विभाजित करें। – Ray

उत्तर

9

धन्यवाद आप प्रत्येक परीक्षण का मामला (जोर) के लिए एक इकाई परीक्षण Assertion Roulette से बचने के लिए लिखना चाहिए।

3

आप एक ही परीक्षा पद्धति में दो परीक्षण कर रहे हैं, तो अपने परीक्षण नहीं कर रहे हैं "इकाई परीक्षण"।

उदाहरण के लिए, यदि पहले null मान के लिए परीक्षण विफल हो जाता है तो क्या होगा?
यदि दोनों परीक्षण एक ही परीक्षण विधि में हैं, तो दूसरा परीक्षण शायद निष्पादित नहीं किया जाएगा; जिसका मतलब है कि दूसरे null मूल्य पर परीक्षण पहले null मान पर परीक्षण पर निर्भर करता है।

दूसरी ओर, यदि आप दो अलग-अलग परीक्षण तरीकों है, तो आप सही अलगाव में प्रत्येक मामले का परीक्षण कर सकते हैं।


आपके MyMethod विधि के कोड से निर्णय लेते हुए, दोनों स्थितियों के बीच कोई संबंध नहीं है; जिसका मतलब है कि उन दो स्थितियों के परीक्षणों के बीच शायद कोई निर्भरता नहीं होनी चाहिए।

तो: आपको दो अलग-अलग परीक्षणों का उपयोग करना चाहिए।

+0

भले ही आप अपने परीक्षणों को समूहबद्ध करते हैं, फिर भी परीक्षण के तहत कोड की आपकी इकाई अभी भी वही है - इसलिए यह अभी भी इकाई परीक्षण है चाहे कोई फर्क नहीं पड़ता: ओ) लेकिन जो आप धीरे-धीरे खो देते हैं वह विफलता को इंगित करने की क्षमता है। व्यावहारिक रूप से यह कई परीक्षणों (= बहुत सारे वाक्यविन्यास) के बीच व्यापार-बंद है, जो इंगित करने की क्षमता बनाते हैं - माइकल का जवाब देखें। – MaR

6

'आदर्श' इकाई परीक्षण परीक्षण एक बात केवल आदेश वास्तव में त्रुटियों को इंगित करने में।

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

अतिरिक्त काम कर रहा है जब परीक्षण लेखन को बचाने के लिए अपने आप को काम जब यह विफल (जो कभी नहीं हो सकता है) YAGNI का एक रूप है।

यदि एकाधिक विधियों को अधिक विधि घोषणाओं को टाइप करने से परे कोई अतिरिक्त काम नहीं है, तो आपको यह करना चाहिए, लेकिन यदि यह डुप्लिकेट सेटअप कोड की ओर जाता है, तो मुझे एक परीक्षण विधि में कई स्थितियों का परीक्षण करने में बिल्कुल कुछ भी गलत नहीं लगता है।

0

एक गैर तकनीकी विचार के लिए extrapolate करने के लिए।

कहें कि आपके पास एक कार है, और आप रंग का परीक्षण करना चाहते हैं।

टेस्ट हो सकता है:

कार लाल है। कार नीली है। कार पेंट की गई है।

अब यह "चित्रित" और "नीला" होना समझ में आता है, लेकिन वे वास्तव में अलग-अलग चीजें हैं। और यदि आप लाल और नीले रंग का परीक्षण करते हैं, तो यह हमेशा असफल रहेगा - या विफलता एक अलगाव दृष्टिकोण से समझ में नहीं आती है।

एक बार जब आप सुझाव देते हैं तो एक चीज का परीक्षण करें, और कई चीजें परीक्षण सूट शामिल हैं।

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