इकाई परीक्षण की समग्र तस्वीर

यह इकाई गाइड पाने के लिए आपको कोड संपादक में कौन से वर्ण दर्ज करने की आवश्यकता है, यह मार्गदर्शिका नहीं है। यह मन के लिए भोजन है, जिसका सेवन इन क्रियाओं को करने से पहले करना चाहिए।

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

परीक्षण क्या है?

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

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

यहाँ एक परीक्षण बनने का मेरा संक्षिप्त इतिहास है:

• 1822 - अंतर इंजन (चार्ल्स बैबेज)।
• 1843 - विश्लेषणात्मक इंजन (एडा लवलेश)।
• 1878 - एडिसन ने "बग" शब्द का परिचय दिया।
• 1957 - कार्यक्रमों (चार्ल्स बेकर) का परीक्षण और डिबगिंग।
• 1958 - पहली सॉफ्टवेयर टेस्टिंग टीम (जेराल्ड वेनबर्ग)।
• 1968 - संकट पीओ (फ्रेडरिक बाउर)।
• 1970 के दशक - झरना मॉडल, संबंधपरक मॉडल, अपघटन, महत्वपूर्ण विश्लेषण ( वॉकथ्रू ), कोड और गुणवत्ता और मेट्रिक्स, डिजाइन पैटर्न का डिजाइन और निरीक्षण।
• 1980 के दशक - सीआरयूडी विश्लेषण, सिस्टम आर्किटेक्चर, ऑटोटस्टिंग, वी-मॉडल, विश्वसनीयता, गुणवत्ता की लागत, उपयोग के तरीके, ओओपी डिजाइन पैटर्न।
• 1990 के दशक में - स्क्रैम, प्रयोज्य परीक्षण, MoSCoW, हेयुरिस्टिक परीक्षण, सॉफ्टवेयर स्वचालन और परीक्षण।

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

• ... - 1956 डिबगिंग
• 1957 - 1978 प्रदर्शन
• 1979 - 1982 का विनाश
• 1983 - 1987 का अनुमान
• 1988 - ... रोकथाम

इसलिए, परियोजना और कार्यान्वयन के बीच विसंगतियों को रोकने के लिए इकाई परीक्षण आवश्यक है।

वास्तव में परीक्षण क्या है?

सॉफ्टवेयर परीक्षण के विभिन्न वर्गीकरण हैं। इकाई परीक्षण के स्थान को बेहतर ढंग से समझने के लिए, मैं केवल सबसे व्यापक दृष्टिकोण का उल्लेख करूंगा।

टेस्ट हैं: स्थिर और गतिशील, "बॉक्स" (सफेद बॉक्स, ब्लैक बॉक्स, ग्रे बॉक्स), स्तर और प्रकार। प्रत्येक दृष्टिकोण विभिन्न वर्गीकरण मानदंडों का उपयोग करता है।

स्थैतिक और गतिशील परीक्षण

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

सही परिणाम प्राप्त करने के लिए डायनामिक परीक्षण को कोड निष्पादन की आवश्यकता होती है। उदाहरण के लिए, यूनिट परीक्षणों , एकीकरण, प्रणाली, स्वीकृति और अन्य परीक्षणों के लिए। यही है, गतिशील डेटा, इनपुट और आउटपुट का उपयोग करके परीक्षण किया जाता है।

बॉक्स दृष्टिकोण

इस दृष्टिकोण के अनुसार, सभी सॉफ्टवेयर परीक्षणों को तीन प्रकार के बॉक्सों में विभाजित किया जाता है:

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

अब, आपको भ्रमित करने के लिए, मेरा कहना है कि इकाई परीक्षण "ब्लैक बॉक्स" पर भी लागू हो सकता है, क्योंकि आप परीक्षण के तहत मॉड्यूल को समझ सकते हैं, लेकिन पूरे सिस्टम को नहीं। हालांकि मेरे लिए यह अभी भी एक "सफेद बॉक्स" है, और मेरा सुझाव है कि आप इससे सहमत हैं।

परीक्षण का स्तर

उनकी संख्या भिन्न होती है, आमतौर पर 4 से 6 की सीमा में, और वे सभी उपयोगी होते हैं। नाम भी अलग-अलग हो सकते हैं, कंपनी द्वारा अपनाई गई संस्कृति के आधार पर, आप "एकीकरण" परीक्षणों को "स्वचालित", "सिस्टम" परीक्षणों को "स्वचालित", और इसी तरह से जान सकते हैं। सादगी के लिए, मैं 5 स्तरों का वर्णन करूंगा:

1. इकाई परीक्षण
2. एकीकरण परीक्षण।
3. परीक्षण घटक इंटरफेस।
4. सिस्टम परीक्षण।
5. संचालन स्वीकृति परीक्षण।

यूनिट परीक्षण कोड के एक विशेष टुकड़े की कार्यक्षमता का परीक्षण करता है, आमतौर पर एक समय में एक कार्य करता है। एकीकरण परीक्षण घटकों के बीच के इंटरफेस की जांच करता है ताकि इकट्ठे किए गए मॉड्यूल एक ऐसी प्रणाली का निर्माण करें जो इच्छित के रूप में काम करती है। यह एक महत्वपूर्ण बिंदु है, क्योंकि बड़ी संख्या में परीक्षण, जिन्हें यूनिट परीक्षण कहा जाता है, वास्तव में एकीकरण परीक्षण हैं, और डेवलपर्स उन्हें मॉड्यूल मानते हैं। यदि आप कई मॉड्यूल का उपयोग करने का इरादा रखते हैं - यह उनके बीच एकीकरण का परीक्षण कर रहा है, न कि स्वयं मॉड्यूल। परीक्षण घटक इंटरफेस विभिन्न मॉड्यूल के बीच स्थानांतरित किए गए डेटा की जांच करता है। उदाहरण के लिए, हमें मॉड्यूल 1 से डेटा प्राप्त हुआ - चेक किया गया - मॉड्यूल 2 में स्थानांतरित - चेक किया गया। सिस्टम परीक्षण सभी आवश्यकताओं के अनुपालन को सत्यापित करने के लिए एंड-टू-एंड परीक्षण है। परिचालन स्वीकृति परीक्षण को परिचालन तत्परता को सत्यापित करने के लिए किया जाता है। यह कार्यात्मक नहीं है, केवल सेवाओं की सेवाक्षमता की जाँच की जाती है, चाहे कोई भी उपतंत्र पर्यावरण और अन्य सेवाओं को नुकसान पहुंचाए।

परीक्षण के प्रकार

प्रत्येक प्रकार के परीक्षण, भले ही इसके स्तर की परवाह किए बिना, अन्य प्रकारों में भी विभाजित किया जा सकता है। 20 से अधिक सामान्य प्रकार हैं। सबसे आम:

• प्रतिगमन परीक्षण ।
• स्वीकृति परीक्षण।
• धुआँ परीक्षण
• UAT
• विनाशकारी परीक्षण ।
• प्रदर्शन परीक्षण।
• निरंतर परीक्षण ।
• प्रयोज्यता परीक्षण।
• सुरक्षा परीक्षण।

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

अब आप जानते हैं कि इकाई परीक्षण गतिशील हैं, "व्हाइट बॉक्स" वर्ग के हैं, मॉड्यूल स्तर पर किए जाते हैं, प्रतिगमन परीक्षण होते हैं, लेकिन यूनिट परीक्षणों को कई प्रकार के परीक्षणों के रूप में समझा जा सकता है। तो यूनिट परीक्षण वास्तव में क्या हैं?

यूनिट परीक्षण क्या है?

एक वी-मॉडल सॉफ्टवेयर विकास जीवन चक्र में उपरोक्त स्तरों, प्रकारों और उनके उद्देश्य का एक चित्रमय प्रतिनिधित्व है।



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

और यह उचित है। यूनिट परीक्षणों के बहुत फायदे हैं। वे हैं:

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

हालाँकि, कुछ सीमाएँ हैं जिनके बारे में आपने सोचा था, शायद इस सूची को पढ़ते समय:

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

बाद वाला मुझे सबसे ज्यादा मारता है। (लगभग) प्रत्येक परियोजना में, काम करने वाले एप्लिकेशन के स्रोत कोड में, मुझे "यदि यह एक इकाई परीक्षण है, तो एक सरोगेट SQLite डेटाबेस को लोड करें, अन्यथा किसी अन्य डेटाबेस को लोड करें", या "यदि यह एक इकाई परीक्षण है, तो एक ईमेल न भेजें, अन्यथा" "जैसे लाइनें ढूंढें। भेजें ”, और इसी तरह। यदि आपके आवेदन में एक खराब वास्तुकला है, तो यह ढोंग न करें कि आप एक अच्छे टेस्ट पास के साथ घटिया सॉफ्टवेयर को ठीक कर सकते हैं, यह इसके लिए बेहतर नहीं होगा।

मैंने अक्सर सहयोगियों और ग्राहकों के साथ चर्चा की कि एक अच्छी इकाई परीक्षण क्या है। वह:

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

"स्वचालित" पढ़ने के बाद धूम्रपान करने वालों के लिए: मेरा मतलब यह नहीं था कि CI पाइपलाइनों में PHPUnit या JUnit को एकीकृत किया जाए। मुद्दा यह है कि यदि आप कोड बदलते हैं, तो इसे सहेजें और यह न जानें कि क्या मॉड्यूल उनके परीक्षण पास करते हैं, तो वे स्वचालित नहीं हैं, लेकिन चाहिए। जीतने का विकल्प फ़ाइल ट्रैकिंग है।

इकाई परीक्षण के अधीन क्या होना चाहिए?

सामान्य प्रणालियों में, इकाई परीक्षणों के लिए लिखा जाना चाहिए:

• मॉड्यूल - सिस्टम के अविभाज्य पृथक हिस्से जो किसी एक कार्य (कार्य, विधि, वर्ग) को करते हैं।
• सार्वजनिक तरीके।
• संरक्षित तरीके, लेकिन केवल दुर्लभ मामलों में और जब कोई नहीं देखता है।
• कीड़े और उनके सुधार।

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

तो आप स्वयं यह निर्धारित कर सकते हैं कि आपके लिए एक मॉड्यूल क्या है। या आप एक-एक करके तरीकों का परीक्षण कर सकते हैं, जिससे उस आदमी के लिए जीवन आसान हो जाएगा जो फिर कोड के साथ काम करेगा।

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

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

क्या परीक्षण करने की आवश्यकता नहीं है

यह निर्धारित करना थोड़ा कठिन है कि आपको परीक्षण करने की आवश्यकता नहीं है। मैंने उन तत्वों की एक सूची संकलित करने की कोशिश की जिन्हें इकाई परीक्षण के अधीन करने की आवश्यकता नहीं है :

• मॉड्यूल के दायरे के बाहर कार्यशीलता (!)
• अन्य मॉड्यूल के साथ मॉड्यूल का एकीकरण (!)
• असंयमित व्यवहार (अचूक निर्भरताएँ, वास्तविक डेटाबेस, नेटवर्क)
• निजी, सुरक्षित तरीके।
• स्थैतिक तरीके।
• बाहरी पुस्तकालय।
• आपका ढाँचा।

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

यूनिट टेस्ट कैसे लिखें?

• इकाई परीक्षण के लिए उपयुक्त कोड लिखें, फिर उसका परीक्षण करें।
• इकाई परीक्षण के लिए उपयुक्त कोड लिखें, फिर उसका परीक्षण करें।
• इकाई परीक्षण के लिए उपयुक्त कोड लिखें, फिर उसका परीक्षण करें।

यदि "फिर यह परीक्षण" पर्याप्त नहीं है, तो laracasts.com में PHP इकाई परीक्षण के बारे में बहुत अच्छे वीडियो हैं। अन्य भाषाओं में समान कार्य के लिए बहुत सारी साइटें समर्पित हैं। मुझे यह समझाने का कोई कारण नहीं है कि मैं यूनिट परीक्षण कैसे करता हूं, क्योंकि उपकरण बहुत जल्दी बदल जाते हैं, और जब आप इस पाठ को पढ़ते हैं, तो मैं PHPUnit से कहलान में स्विच कर सकता हूं। या नहीं। कौन जानता है।

लेकिन पहले सवाल का जवाब देने के लिए (यूनिट परीक्षण के लिए उपयुक्त कोड कैसे लिखें) बहुत आसान है, और स्थिति समय के साथ बदलने की संभावना नहीं है:

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

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

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