जूनिट परीक्षण शून्य विधियों

Question

मेरे पास शून्य विधियों से भरा जावा क्लास है, और मैं अधिकतम कोड कवरेज प्राप्त करने के लिए कुछ यूनिट परीक्षण करना चाहता हूं।

उदाहरण के लिए मैं इस विधि है:

protected static void checkifValidElements(int arg1, int arg2) { 
    method1(arg1); 
    method2(arg1); 
    method3(arg1, arg2); 
    method4(arg1, arg2); 
    method5(arg1); 
    method6(arg2); 
    method7(); 
} 

इसकी क्योंकि मैं बेहतर समझ के लिए कोड अनुवाद खराब एक कारण के लिए नामित किया गया। प्रत्येक विधियां सत्यापित करती हैं कि तर्क किसी तरीके से मान्य हैं और अच्छी तरह से लिखे गए हैं।

उदाहरण:

private static void method1(arg1) { 
    if (arg1.indexOf("$") == -1) { 

     //Add an error message 
     ErrorFile.errorMessages.add("There is a dollar sign in the specified parameter"); 
    } 
} 

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

एक ही रास्ता मैं देख रहा हूँ इस विधि बदलने के लिए एक पूर्णांक या bollean मान देने के लिए, इस तरह है:

protected static int checkifValidElements(int arg1, int arg2) { 
    method1(arg1); 
    method2(arg1); 
    method3(arg1, arg2); 
    method4(arg1, arg2); 
    method5(arg1); 
    method6(arg2); 
    method7(); 
    return 0; 
} 

इस विधि मैं एक ज़ोर के बराबर होती है ऐसा करने में सक्षम हूँ के साथ

, लेकिन यह है कि मुझे लगता है ऐसा करने के लिए व्यर्थ है। समस्या यह है कि मेरे पास कुछ कक्षाएं हैं जो इस तरह डिज़ाइन की गई हैं और यह मेरी इकाई परीक्षण कवरेज% को कम कर रही है।

Answer 1

मैं अधिक से अधिक कोड कवरेज

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

लेकिन मैं नहीं देखता कि मैं अपनी विधि जांच IFValidElements का परीक्षण कैसे कर सकता हूं, यह कुछ भी नहीं देता है या कुछ भी नहीं बदलता है। दोनों गलत तर्क के साथ और एक वैध तर्क के साथ, ErrorFile हर बार के परिणामों की जाँच -

वैसे आप शायद कुछ परीक्षण है, जो उन दोनों के बीच की जाँच है कि सभी 7 तरीकों उचित रूप से कहा जाता है देना चाहिए।

उदाहरण के लिए, मान लीजिए किसी को कॉल हटाया:

method4(arg1, arg2); 

... या गलती से तर्क क्रम बदल:

method4(arg2, arg1); 

आप उन समस्याओं को कैसे नोटिस होगा? उस से जाओ, और इसे साबित करने के लिए डिजाइन परीक्षण।

Answer 2

आप अभी भी एक वैध विधि का परीक्षण कर सकते हैं कि यह उचित दुष्प्रभाव था।

public void checkIfValidElementsWithDollarSign() { 
    checkIfValidElement("$",19); 
    assert ErrorFile.errorMessages.contains("There is a dollar sign in the specified parameter"); 
} 

Answer 3

मुझे लगता है कि आप लेखन पक्ष प्रभावशाली विधि से बचना चाहिए: अपने method1 उदाहरण में, अपने इकाई परीक्षण कुछ की तरह लग रहे हो सकता है। अपनी विधि से सच या गलत लौटें और आप इन तरीकों को यूनिट परीक्षणों में देख सकते हैं।

Answer 4

यदि आपकी विधि का कोई दुष्प्रभाव नहीं है, और कुछ भी वापस नहीं करता है, तो यह कुछ भी नहीं कर रहा है।

यदि आपकी विधि कुछ गणना करता है और उस गणना के परिणाम देता है, तो आप स्पष्ट रूप से पर्याप्त जोर दे सकते हैं कि परिणाम लौटाया गया सही है।

यदि आपका कोड कुछ भी वापस नहीं करता है लेकिन साइड इफेक्ट्स हैं, तो आप कोड को कॉल कर सकते हैं और फिर जोर दे सकते हैं कि सही दुष्प्रभाव हुए हैं। साइड इफेक्ट्स क्या निर्धारित करेंगे कि आप चेक कैसे करते हैं।

आपके उदाहरण में, आप अपने गैर-रिटर्निंग फ़ंक्शंस से स्थैतिक विधियों को कॉल कर रहे हैं, जो इसे तब तक मुश्किल बना देता है जब तक आप निरीक्षण नहीं कर सकते कि उन सभी स्थिर तरीकों का परिणाम सही है। एक बेहतर तरीका - एक परीक्षण बिंदु से - वास्तविक वस्तुओं को इंजेक्ट करना है जिसमें आप विधियों को कॉल करते हैं। फिर आप अपने यूनिट परीक्षण में मॉक ऑब्जेक्ट बनाने के लिए EasyMock या Mockito जैसे कुछ का उपयोग कर सकते हैं, और कक्षा में नकली ऑब्जेक्ट इंजेक्ट कर सकते हैं। मॉक ऑब्जेक्ट तब आपको जोर देता है कि सही कार्यों को सही मानों और सही क्रम में सही कहा गया था।

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

private ErrorFile errorFile; 

public void setErrorFile(ErrorFile errorFile) { 
    this.errorFile = errorFile; 
} 

private void method1(arg1) { 
    if (arg1.indexOf("$") == -1) { 

     //Add an error message 
     errorFile.addErrorMessage("There is a dollar sign in the specified parameter"); 
    } 
} 

फिर अपने परीक्षण में आप लिख सकते हैं:

public void testMethod1() { 
    ErrorFile errorFile = EasyMock.createMock(ErrorFile.class); 
    errorFile.addErrorMessage("There is a dollar sign in the specified parameter"); 
    EasyMock.expectLastCall(errorFile); 
    EasyMock.replay(errorFile); 

    ClassToTest classToTest = new ClassToTest(); 
    classToTest.setErrorFile(errorFile); 
    classToTest.method1("a$b"); 

    EasyMock.verify(errorFile); // This will fail the test if the required addErrorMessage call didn't happen 
} 

Answer 5

यदि आपका विधि शून्य है और आप अपवाद के लिए जाँच करना चाहते हैं, तो आप expected इस्तेमाल कर सकते हैं: https://weblogs.java.net/blog/johnsmart/archive/2009/09/27/testing-exceptions-junit-47

Answer 6

आप "मॉकिंग" नामक कुछ सीख सकते हैं। उदाहरण के लिए, आप इसका उपयोग कर सकते हैं, उदाहरण के लिए, यह जांचने के लिए कि: - फ़ंक्शन को कहा जाता था - एक फ़ंक्शन को x times कहा जाता था - एक फ़ंक्शन को कम से कम x बार कहा जाता था - एक फ़ंक्शन को पैरामीटर के विशिष्ट सेट के साथ बुलाया जाता था। आपके मामले में, उदाहरण के लिए, आप यह जांचने के लिए मॉकिंग का उपयोग कर सकते हैं कि विधि 3 को जिसे आप arg1 और arg2 के रूप में पास करते हैं, के साथ एक बार बुलाया गया था। https://code.google.com/p/mockito/ https://code.google.com/p/powermock/