एक IF स्टेटमेंट में यूनिट कई स्थितियों का परीक्षण करती है

Question

मेरे पास कोड का एक हिस्सा है जो कुछ इस तरह दिखता है:

function bool PassesBusinessRules()
{
    bool meetsBusinessRules = false;

    if (PassesBusinessRule1 
         && PassesBusinessRule2
         && PassesBusinessRule3)
    {
         meetsBusinessRules= true;
    }

    return meetsBusinessRules;
}

मेरा मानना ​​है कि इस विशेष समारोह के लिए चार यूनिट परीक्षण होने चाहिए। तीन बयान में प्रत्येक स्थिति का परीक्षण करने के लिए और सुनिश्चित करें कि यह गलत है। और एक और परीक्षा जो सुनिश्चित करती है कि फ़ंक्शन सही है।

प्रश्न: क्या वास्तव में इसके बजाय दस यूनिट परीक्षण होना चाहिए? नौ जो संभावित विफलता पथों में से प्रत्येक की जाँच करता है। अर्थात:

• झूठा झूठा झूठा
• झूठा झूठा सच
• झूठा सच्चा झूठा

और इसलिए प्रत्येक संभव संयोजन के लिए।

मुझे लगता है कि यह ओवरकिल है, लेकिन मेरी टीम के कुछ अन्य सदस्य नहीं हैं। जिस तरह से मैं इसे देखता हूं अगर BusinessRule1 विफल हो जाता है तो इसे हमेशा गलत तरीके से लौटना चाहिए, इससे कोई फर्क नहीं पड़ता कि इसे पहले या आखिरी बार चेक किया गया था।

Comments

कंपाइलर && ऑपरेटर के लिए लालची मूल्यांकन का उपयोग करता है?

— सुस्ज़ेरपट्ट

यदि आपने 10 यूनिट परीक्षण लिखे हैं, तो आप अपने तरीकों का परीक्षण कर रहे हैं && ऑपरेटर।

— मर्ट अक्काकाया

यदि आप सभी संभावित संयोजनों का परीक्षण करते हैं तो केवल आठ परीक्षण नहीं होंगे? तीन बूलियन पैरामीटर या तो चालू या बंद हो गए।

— क्रिश हार्पर

@ मैर्ट: केवल अगर आप गारंटी दे सकते हैं कि && हमेशा रहेगा।

— मिसको जूल

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

— जॉब

Answer 1

औपचारिक रूप से, उन प्रकार के कवरेज के नाम हैं।

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

फिर वहाँ शर्त कवरेज : यहाँ आप परीक्षण करना चाहते हैं कि प्रत्येक उप शर्त सही और गलत है। यह स्पष्ट रूप से अधिक परीक्षण बनाता है, लेकिन यह आमतौर पर अधिक बग पकड़ता है, इसलिए आपके पास समय होने पर अपने टेस्ट सूट में शामिल करना अक्सर एक अच्छा विचार होता है।

सबसे उन्नत कवरेज मानदंड को आमतौर पर कॉम्बिनेटरियल कंडीशन कवरेज कहा जाता है : यहां लक्ष्य एक परीक्षण मामला है जो आपके परीक्षण में बूलियन मूल्यों के सभी संभावित संयोजनों से गुजरता है ।

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

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

Comments

यदि बूलियन मान बाहरी स्रोतों से पारित किए गए हैं (जिसका अर्थ है कि वे हमेशा मान्य नहीं हैं), तो दहनशील सशर्त कवरेज अक्सर आवश्यक होता है। पहले संयोजनों की एक तालिका बनाएं। फिर, प्रत्येक प्रविष्टि के लिए, तय करें कि क्या प्रविष्टि एक सार्थक उपयोग के मामले का प्रतिनिधित्व करती है। यदि नहीं, तो उस संयोजन को निष्पादित होने से रोकने के लिए कहीं न कहीं कोड होना चाहिए (या तो सॉफ़्टवेयर अभिकथन या सत्यापन क्लॉज़)। यह महत्वपूर्ण है कि सभी मानकों को एक एकल दहनशील परीक्षण में न तोलें: मापदंडों को उन समूहों में विभाजित करने का प्रयास करें जो एक दूसरे के साथ बातचीत करते हैं अर्थात एक ही बूलियन अभिव्यक्ति को साझा करते हैं।

— ४

बोल्ड शब्दों में से कितने निश्चित हैं? आपका उत्तर "कॉम्बीनेटरियल कंडीशन कवरेज" की एकमात्र घटना प्रतीत होता है, और कुछ संसाधनों का कहना है कि "प्रिडेटेट कवरेज" और "सशर्त कवरेज" एक ही बात है।

— स्टिजेन

Answer 2

अंततः, यह आप (आर टीम), कोड और विशिष्ट परियोजना पर्यावरण पर निर्भर करता है। कोई सार्वभौमिक नियम नहीं है। आपको (r टीम) को उतने ही परीक्षण लिखने चाहिए जितने आपको सहज महसूस करने की आवश्यकता है कि कोड वास्तव में सही है । इसलिए यदि आपके टीम के साथी 4 परीक्षणों से आश्वस्त नहीं हैं, तो शायद आपको और अधिक की आवश्यकता है।

यूनिट टेस्ट लिखने के लिए OTOH का समय आमतौर पर एक दुर्लभ संसाधन होता है। इसलिए आपके पास सीमित समय बिताने का सबसे अच्छा तरीका खोजने का प्रयास करें । उदाहरण के लिए, यदि आपके पास 0% कवरेज के साथ एक और महत्वपूर्ण विधि है, तो इस पद्धति के लिए अतिरिक्त परीक्षणों को जोड़ने के बजाय, उस एक को कवर करने के लिए कुछ इकाई परीक्षण लिखना बेहतर हो सकता है। बेशक, यह इस बात पर भी निर्भर करता है कि प्रत्येक का कार्यान्वयन कितना नाजुक है। निकट भविष्य में इस विशेष पद्धति में बहुत सारे बदलावों की योजना बनाना अतिरिक्त इकाई परीक्षण कवरेज को सही ठहरा सकता है। तो कार्यक्रम के अंदर एक महत्वपूर्ण पथ पर हो सकता है। ये सभी कारक हैं जो केवल आप (आर टीम) का आकलन कर सकते हैं।

मैं व्यक्तिगत रूप से आपके द्वारा उल्लिखित 4 परीक्षणों से खुश होऊंगा, अर्थात्:

• सच्ची झूठी झूठी
• झूठी सच्ची झूठी
• झूठी झूठी सच्ची
• सच्चा सच्चा सच्चा

प्लस शायद एक:

• सच्चा सच्चा झूठा

यह सुनिश्चित करने के लिए कि वापसी मूल्य प्राप्त करने का एकमात्र तरीका trueसभी 3 व्यावसायिक नियमों को पूरा करना है। लेकिन अंत में, यदि आपके टीम के साथी कम्बिनेटरियल रास्तों को कवर करने पर जोर देते हैं, तो उन अतिरिक्त परीक्षणों को जोड़ना सस्ता हो सकता है जो तर्क को लंबे समय तक जारी रखने के लिए :-)

Answer 3

यदि आप सुरक्षित रहना चाहते हैं, तो आपको तीन वैरिएबल ट्रुथ टेबल ( http://teach.valdosta.edu/plmoch/MATH4161/Spring%202004/and_or_if_files/image006.gif ) द्वारा दर्शाई गई स्थितियों का उपयोग करके आठ इकाई परीक्षणों की आवश्यकता होगी ।

आप कभी भी यह सुनिश्चित नहीं कर सकते कि व्यापार तर्क हमेशा यह निर्धारित करेगा कि चेक उसी क्रम में किए गए हैं और आप चाहते हैं कि परीक्षण वास्तविक कार्यान्वयन के बारे में जितना संभव हो उतना कम पता हो।

Comments

इकाई परीक्षण है सफेद बॉक्स टेस्टिंग।

— पेर्ट तोर्क

अच्छी तरह से आदेश मायने नहीं रखता, और& साम्यवादी है, या कम से कम होना चाहिए

— Zachary K

Answer 4

हां, एक आदर्श दुनिया में पूर्ण संयोजन होना चाहिए।

यूनिट परीक्षण करते समय, आपको वास्तव में यह अनदेखा करने का प्रयास करना चाहिए कि विधि अपना काम कैसे करती है। बस 3 इनपुट प्रदान करें और सत्यापित करें कि आउटपुट सही है।

Comments

इकाई परीक्षण है सफेद बॉक्स टेस्टिंग। और हम एक आदर्श दुनिया में नहीं रहते हैं।

— पेटर तोरॉक

@ PéterTörök - हम सुनिश्चित करने के लिए एक आदर्श दुनिया में नहीं रहते, लेकिन stackexchange अन्य बिंदु पर आप से असहमत। विशेष रूप से टीडीडी के लिए, परीक्षणों को विनिर्देशों के लिए लिखा जाता है, कार्यान्वयन नहीं। मैं व्यक्तिगत रूप से सभी विशेषताओं (सदस्य चर सहित) और सभी आउटपुट (साइड इफेक्ट सहित) शामिल करने के लिए 'विनिर्देश' लेता हूं।

— तेलेस्टीन

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

— 20-13 पर पेर्ट टॉर्क

Answer 5

राज्य बुराई है। निम्नलिखित फ़ंक्शन को एक इकाई परीक्षण की आवश्यकता नहीं है क्योंकि इसका कोई दुष्प्रभाव नहीं है और यह अच्छी तरह से समझा जाता है कि यह क्या करता है और क्या नहीं करता है। इसका परीक्षण क्यों? क्या आपको अपने दिमाग पर भरोसा नहीं है ??? स्थैतिक कार्य महान हैं!

static function bool Foo(bool a, bool b, bool c)
{
    return a && b && c;
}

Comments

नहीं, मुझे अपने स्वयं के मस्तिष्क पर भरोसा नहीं है - मैंने हमेशा यह जानने का कठिन तरीका सीखा कि मैं क्या करता हूं :-) इसलिए मुझे यह सुनिश्चित करने के लिए इकाई परीक्षणों की आवश्यकता होगी कि मैंने कुछ गलत नहीं किया है, और यह भी है कि कोई भी नहीं जा रहा है भविष्य में कोड को तोड़ने के लिए। और कॉलर विधि को सत्यापित करने के लिए अधिक इकाई परीक्षण जो राज्य द्वारा प्रतिनिधित्व की गणना करता है a, bऔर c। आप किसी भी तरह से व्यापार तर्क को स्थानांतरित कर सकते हैं जो आप चाहते हैं, अंत में आपको अभी भी कहीं न कहीं इसका परीक्षण करने की आवश्यकता है।

— पेर्ट तोर्क

@ Péter Török, आप अपने परीक्षणों में टाइपो भी बना सकते हैं और इस तरह झूठी सकारात्मकता के साथ समाप्त हो सकते हैं, तो आप कहाँ रुकते हैं? क्या आप अपनी इकाई परीक्षणों के लिए इकाई परीक्षण लिखते हैं? मुझे अपने मस्तिष्क पर 100% भी भरोसा नहीं है, लेकिन दिन के अंत में कोड लिखना है जो मैं जीवनयापन के लिए करता हूं। इस फ़ंक्शन के अंदर एक बग होना संभव है, लेकिन कोड को इस तरह से लिखना महत्वपूर्ण है कि बग को स्रोत का पता लगाना आसान होगा और ताकि एक बार जब आप समस्या को अलग कर लें और ठीक कर लें, तो आप बेहतर बंद हो जाएंगे । अच्छी तरह से लिखा कोड एकीकरण पर भरोसा कर सकता है परीक्षण ज्यादातर infoq.com/pretations/Simple-Made-Easy

— नौकरी

वास्तव में परीक्षण दोषपूर्ण भी हो सकते हैं। (टीडीडी पहले परीक्षणों को विफल बनाकर इसे स्वीकार करता है।) हालांकि, दो बार एक ही तरह की त्रुटि करना (और इसे अनदेखा करना) बहुत कम संभावना है। सामान्य तौर पर, कोई राशि और परीक्षण के प्रकार के कर सकते हैं साबित है कि सॉफ्टवेयर बग-मुक्त है, बस को कम एक स्वीकार्य स्तर तक कीड़े की संभावना। और स्रोत के लिए बग को ट्रेस करने की गति में, IMO कुछ भी यूनिट परीक्षणों को हरा नहीं सकता है - फास्ट फीडबैक नियमz :-)

— पेटर टॉर्क

"निम्नलिखित फ़ंक्शन को एक इकाई परीक्षण की आवश्यकता नहीं है" मुझे लगता है कि आप यहां व्यंग्यात्मक हो रहे हैं, लेकिन यह स्पष्ट नहीं है। क्या मुझे अपने मस्तिष्क पर भरोसा है? नहीं! क्या मुझे उस अगले आदमी के दिमाग पर भरोसा है जो कोड को छूता है? अधिक नहीं! क्या मुझे भरोसा है कि कोड के पीछे की सभी धारणाएं अब से एक साल बाद सच होंगी? ... तुम मेरा बहाव हो जाओ। इसके अलावा, स्थैतिक कार्य OO को मारते हैं ... यदि आप एफपी करना चाहते हैं, तो एफपी भाषा का उपयोग करें।

— रोब

Answer 6

मुझे पता है कि यह सवाल काफी पुराना है। लेकिन मैं समस्या को एक और परिप्रेक्ष्य देना चाहता हूं।

सबसे पहले, आपके यूनिट परीक्षणों के दो उद्देश्य होने चाहिए:

1. आपके और आपकी टीम के साथियों के लिए प्रलेखन बनाएं, इसलिए दिए गए समय के बाद आप इकाई परीक्षण पढ़ सकते हैं और सुनिश्चित कर सकते हैं कि आप समझ गए हैं what's the class' intentionऔरhow the class is doing its work
2. विकसित करते समय, इकाई परीक्षण यह सुनिश्चित करता है कि हम जो कोड लिख रहे हैं वह अपना काम कर रहा है जैसा कि हमारे दिमाग में था।

इसलिए, समस्या को याद करते हुए, हम ए का परीक्षण करना चाहते हैं complex if statement, दिए गए उदाहरण के लिए, 2 ^ 3 संभावनाएं हैं, यह एक महत्वपूर्ण राशि है जो हम लिख सकते हैं।

• आप इस तथ्य के अनुकूल हो सकते हैं और 8 परीक्षण लिख सकते हैं या पैरामीरिज्ड परीक्षणों का उपयोग कर सकते हैं
• आप अन्य उत्तरों का भी अनुसरण कर सकते हैं और याद रख सकते हैं कि परीक्षण इरादे के साथ स्पष्ट होने चाहिए, इस तरह हम बहुत अधिक विवरणों के साथ गड़बड़ नहीं करने वाले हैं कि निकट भविष्य में समझने में मुश्किल हो सकती है what is doing the code

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

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

If some simple business rule apply, derive to the next handler

एक जटिल नियम के बजाय विभिन्न सरल नियमों का परीक्षण करना कितना सरल होगा?

आशा करता हूँ की ये काम करेगा,

Answer 7

यह उन मामलों में से एक है जहां क्विकचेक ( http://en.wikipedia.org/wiki/QuickCheck ) जैसा कुछ आपका दोस्त होगा। हाथ से सभी एन मामलों को लिखने के बजाय कंप्यूटर ने संभावित परीक्षण मामलों की सभी (या कम से कम बड़ी संख्या) उत्पन्न की है और सभी को एक समझदार परिणाम लौटाते हैं।

हम यहां एक रहने के लिए कंप्यूटर प्रोग्राम करते हैं, तो आपके लिए अपने परीक्षण मामलों को उत्पन्न करने के लिए कंप्यूटर को प्रोग्राम क्यों नहीं करते हैं?

Answer 8

आप गार्ड की स्थितियों में शर्तों को वापस कर सकते हैं:

if (! PassesBusinessRule1) {
    return false;
}

if (! PassesBusinessRule2) {
    return false;
}

if (! PassesBusinessRule3) {
    return false;
}

मुझे नहीं लगता कि इससे मामलों की संख्या कम होती है, लेकिन मेरा अनुभव यह है कि उन्हें इस तरह से तोड़ना आसान है।

(ध्यान दें कि मैं एक बड़ा "एक्जिट ऑफ एक्जिट" फैन हूं, लेकिन मैं गार्ड की स्थिति के लिए एक अपवाद बनाता हूं। लेकिन कोड को स्ट्रक्चर करने के अन्य तरीके हैं ताकि आपके पास अलग रिटर्न न हो।)