मुझे विधि में शून्य और/या खाली स्ट्रिंग पैरामीटर का परीक्षण कैसे करना चाहिए?

Question

यह इस उदाहरण के रूप में स्ट्रिंग पैरामीटर के साथ तरीकों कि के खिलाफ शून्य या खाली मान्य किया जाना चाहिए, साथ वर्गों के लिए आम बात है:

public class MyClass { 

    public void MyMethod(string param){ 

     if(string.IsNullOrEmpty(param)){ 
      throw new ArgumentNullException(...); 
     } 
     //... 
    } 
} 

ऐसा नहीं है कि विधि के व्यवहार दोनों के लिए समान है स्पष्ट है (अवैध) मान। यह एक बहुत ही आम स्थिति है, और जब इन तरीकों का परीक्षण करने की बात आती है, तो मुझे हमेशा यह संदेह होता है कि इसे कैसे किया जाए। मैं हमेशा इन मामलों के लिए दो अलग-अलग परीक्षणों का निर्माण:

[TestClass] 
public class Tests { 

    [TestMethod] 
    public void MyMethod_should_fail_if_param_is_null(){ 
     //... 
     myclass.MyMethod(null); 
     //... 
    } 

    [TestMethod] 
    public void MyMethod_should_fail_if_param_is_empty(){ 
     //... 
     myclass.MyMethod(""); 
     //... 
    } 

}

लेकिन मैं बहुत ज्यादा अतिरेक देखते हैं। वे परीक्षण बिल्कुल वही हैं, विधि में पारित पैरामीटर केवल अंतर ही है। इससे मुझे बहुत परेशान होता है, क्योंकि मुझे प्रत्येक स्ट्रिंग पैरामीटर के लिए दो टेस्ट बनाना पड़ता है। 3 पैरामीटर वाले एक विधि में पैरामीटर का परीक्षण करने के लिए केवल 6 परीक्षण होंगे।

मुझे लगता है कि यह उन मानकों का परीक्षण करने का सही तरीका है, लेकिन अगर मुझे पता है कि 99% स्ट्रिंग पैरामीटर एक ही तरीके से मान्य किए जाएंगे, तो बेहतर होगा कि उन्हें नल (या खाली) के लिए परीक्षण न करें और मान लें कि दूसरे मामले में व्यवहार वही होगा?

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

धन्यवाद!

Answer 1

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

महत्वपूर्ण बात यह सुनिश्चित करना है कि मामले की जांच के लिए आपको एक छोटा सा कट मिला है। उदाहरण के लिए, आप कुछ इस तरह लिख सकते हैं (यदि आपके इकाई परीक्षण रूपरेखा यह पहले से ही नहीं है):

public static void ExpectException<T>(Action action) where T : Exception 
{ 
    try 
    { 
     action(); 
     Assert.Fail("Expected exception " + typeof(T).Name); 
    } 
    catch (T exception) 
    { 
     // Expected 
    } 
} 

तो फिर तुम लिख सकते हैं:

[Test] 
public void MyMethodFailsWithInvalidArguments() 
{ 
    ExpectException<ArgumentNullException>(() => myClass.MyMethod(null)); 
    ExpectException<ArgumentException>(() => myClass.MyMethod("")); 
} 

बहुत हर एक के साथ क्या कर की तुलना में अधिक संक्षिप्त

एक व्यक्ति कोशिश/पकड़ ब्लॉक, या यहां तक ​​कि ExpectedException विशेषता और एकाधिक परीक्षण का उपयोग कर।

आप ऐसे मामलों में जहां आप भी सत्यापित करने के लिए कि प्रत्येक मामले में चाहते हैं के लिए भार के लिए चाहते हो सकता है, कोई मज़ाक उड़ाया वस्तुओं को छुआ गया है ArgumentNullException की तरह आम अपवाद के लिए (कि दुष्प्रभाव परहेज कर रहे हैं की जाँच करने के) या संभवतः भार के।

एकल पैरामीटर तरीकों के लिए आप भी संपुटित के लिए एक विधि आप वास्तव में क्या जरूरत है लिख सकते हैं:

public void ExpectExceptionForNullAndEmptyStrings(Action<string> action) 
{ 
    ExpectException<ArgumentNullException>(() => action(null)); 
    ExpectException<ArgumentException>(() => action("")); 
} 

तो से कॉल करने की:

[Test] 
public void MyMethodFailsWithInvalidArguments() 
{ 
    // This *might* work without the 
    ExpectExceptionForNullAndEmptyStrings(myClass.MyMethod); 
} 

... और हो सकता है तरीकों के लिए एक दूसरे से एक पैरामीटर के साथ लेकिन एक गैर-शून्य वापसी प्रकार।

कि संभवतः एक सा दूर हालांकि :)

Answer 2

जा रहा है आप जावा और JUnit का उपयोग करते हैं तो आप इस वाक्य रचना

@Test(expected = IllegalArgumentException.class) 
public void ArgumentTest() { 
    myClass.MyMethod(""); 
    myClass.MyMethod(null); 
}