विश्वसनीय इकाई परीक्षण करने के दो तरीके

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

इसका एक कारण है, लेकिन क्या यूनिट परीक्षण वास्तव में अपूर्ण हैं और क्या उन्हें अधिक विश्वसनीय बनाया जा सकता है? उनके अधूरेपन के कितने कारण हैं?

मान लीजिए कि हमारे पास दो यूनिट-टेस्ट-कवर किए गए घटक हैं, कॉलर और कैली। कॉलर एक तर्क के साथ कैली को बुलाता है और किसी तरह लौटी हुई वस्तु का उपयोग करता है। प्रत्येक घटक की अपनी निर्भरता का अपना सेट है, जिसे हम सोख लेते हैं।

एकीकरण के दौरान ये घटक कितने परिदृश्यों में अप्रत्याशित रूप से व्यवहार करते हैं?

पहला परिदृश्य दोनों घटकों के लिए बाहरी समस्या है । उदाहरण के लिए, वे दोनों डेटाबेस की स्थिति, प्राधिकरण, पर्यावरण चर, वैश्विक चर, कुकीज़, फाइलें आदि पर निर्भर करते हैं। यह देखते हुए काफी सरल है, क्योंकि बहुत बड़े कार्यक्रमों में भी आमतौर पर सीमित संख्या में ऐसे विवाद बिंदु होते हैं।

समस्या को हल किया जा सकता है, जाहिर है, या तो कम निर्भरता के साथ एक नया स्वरूप के माध्यम से,
या हम सीधे किसी शीर्ष-स्तरीय परिदृश्य में संभावित त्रुटि का अनुकरण करते हैं, अर्थात, हम CallingStrategy घटक (OffendingCaller, OffendedCallee) {} का परिचय देते हैं, और CallleyStrategy में कैली क्रैश और त्रुटि से निपटने का अनुकरण करते हैं। इसके लिए, एकीकरण परीक्षणों की आवश्यकता नहीं होती है, लेकिन एक समझ की आवश्यकता होती है कि किसी एक घटक का विशिष्ट व्यवहार दूसरे घटक के लिए जोखिम पैदा करता है, और इस परिदृश्य को एक घटक में अलग करना अच्छा होगा।

दूसरा परिदृश्य: समस्या पूर्णांक वस्तुओं के इंटरफेस में है, अर्थात। वस्तुओं में से एक की एक अनावश्यक स्थिति दूसरे में लीक हो गई है ।

वास्तव में, यह इंटरफ़ेस में एक दोष है जो इसे अनुमति देता है। समस्या का समाधान भी काफी स्पष्ट है - टाइपिंग और इंटरफेस को कम करना, मापदंडों का प्रारंभिक सत्यापन।

जैसा कि हम देख सकते हैं, दोनों कारण बेहद सामान्य हैं, लेकिन यह स्पष्ट रूप से स्पष्ट करना अच्छा होगा कि कोई अन्य नहीं है।

इस प्रकार, यदि हमने 1) आंतरिक स्थिति और 2) बाहरी निर्भरता के लिए हमारी कक्षाओं की जाँच की, तो हमारे पास इकाई परीक्षणों की विश्वसनीयता पर संदेह करने का कोई कारण नहीं है।

(कोने में, एक कार्यात्मक प्रोग्रामर "मैंने आपको ऐसा कहा था," शब्दों के साथ चुपचाप रो रहा है, लेकिन उस अधिकार के बारे में नहीं)।

लेकिन हम किसी तरह की लत को भूल सकते हैं या याद कर सकते हैं!

निर्दयता से अनुमान लगाया जा सकता है। मान लीजिए कि प्रत्येक घटक में दस परिदृश्य हैं। हम दस में से एक परिदृश्य को छोड़ते हैं। उदाहरण के लिए, कैली अचानक अशक्त हो जाता है, और कॉलर को अचानक एक NullPointerException प्राप्त होती है। हमें दो बार गलती करने की आवश्यकता है, जिसका अर्थ है कि कहीं गिरने की संभावना 1/100 है। यह कल्पना करना कठिन है कि दो तत्वों के लिए एकीकरण परिदृश्य इसे पकड़ लेगा। एकीकरण परीक्षण के भीतर कई क्रमिक रूप से बुलाए गए घटकों के लिए, त्रुटियों में से एक को पकड़ने की संभावना बढ़ जाती है, जिसका अर्थ है कि एकीकरण परीक्षण का लंबा समय, और अधिक परिदृश्य, और अधिक न्यायसंगत है।

(संचित त्रुटियों का वास्तविक गणित, ज़ाहिर है, बहुत अधिक जटिल है, लेकिन परिणाम बहुत भिन्न नहीं है)।

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

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