मुझे लगता है कि यूनिट परीक्षण की आपकी अवधारणा सही नहीं है। तकनीकी रूप से बोलते हुए, "यूनिट परीक्षण" एक सॉफ्टवेयर सत्यापन और सत्यापन विधि है जिसमें एक प्रोग्रामर परीक्षण करता है यदि स्रोत कोड की अलग-अलग इकाइयां उपयोग के लिए उपयुक्त हों। एक इकाई एक आवेदन का सबसे छोटा टेस्टेबल हिस्सा है। प्रक्रियात्मक प्रोग्रामिंग में एक इकाई एक व्यक्तिगत कार्य या प्रक्रिया हो सकती है और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में यह कक्षा का एक तरीका हो सकता है।
आप जो करना चाहते हैं वह मूल रूप से "छोटे कार्यक्रमों को पहले और फिर धीरे-धीरे जटिल बनाते हैं (और निश्चित रूप से आप अंततः प्रोग्रामिंग सीखेंगे)"। इस प्रकार के सॉफ्टवेयर विकास "सरल से शुरू होते हैं और फिर इसे धीरे-धीरे जटिल बनाते हैं" को तकनीकी रूप से "सॉफ्टवेयर प्रोटोटाइप" कहा जाता है। यहां इसकी परिभाषा है:
"सॉफ्टवेयर प्रोटोटाइप, कुछ सॉफ्टवेयर विकास के दौरान एक गतिविधि प्रोटोटाइप का निर्माण है, यानी, सॉफ्टवेयर प्रोग्राम के अपूर्ण संस्करण विकसित किए जा रहे हैं। एक प्रोटोटाइप आम तौर पर अंतिम कार्यक्रम की विशेषताओं के कुछ पहलुओं को अनुकरण करता है, और अंतिम कार्यान्वयन से पूरी तरह अलग हो सकता है। प्रोटोटाइप का पारंपरिक उद्देश्य सॉफ़्टवेयर के उपयोगकर्ताओं को विवरणों के आधार पर डिज़ाइन की व्याख्या और मूल्यांकन करने के बजाय, वास्तविक उत्पाद के डिज़ाइन के लिए डेवलपर के प्रस्तावों का मूल्यांकन करने की अनुमति देना है। प्रोटोटाइप का उपयोग अंत उपयोगकर्ताओं द्वारा डेवलपर्स के विचारों को वर्णित करने और साबित करने के लिए भी नहीं किया जा सकता है, इसलिए "प्रोटोटाइप को नियंत्रित करना" समाधान प्रदाताओं और उनके ग्राहकों के बीच वाणिज्यिक संबंधों में एक महत्वपूर्ण कारक हो सकता है। "
दूसरी ओर हाथ, यूनिट परीक्षण "सॉफ्टवेयर परीक्षण" में एक पद्धति है। यह सॉफ्टवेयर विकास की शुरुआत का हिस्सा नहीं है। यह अंत में किया जाता है जब काफी बड़ा कार्यक्रम बनाया गया है और यह सुनिश्चित करने के लिए कि प्रत्येक टुकड़ा (यानी छोटी इकाइयां जैसे कार्यों, प्रक्रियाओं, कक्षा विधियों इत्यादि) सही तरीके से काम कर रहे हैं। यूनिट परीक्षण का उपयोग सॉफ्टवेयर विकास के आधार पर नहीं किया जा सकता है क्योंकि अंत में यूनिट परीक्षण के परिणामस्वरूप "किसी एक टुकड़े में त्रुटि होती है" इसका निश्चित रूप से मतलब है कि पूरा सॉफ़्टवेयर गलत है यदि यूनिट परीक्षण कहता है "सभी टुकड़ों में कोई त्रुटि नहीं है, इसका मतलब यह नहीं है कि पूरा सॉफ़्टवेयर त्रुटि मुक्त है ई "क्योंकि उन टुकड़ों को एकीकृत करने में कुछ त्रुटि हो सकती है या यूनिट परीक्षण से कार्यक्रम में हर त्रुटि को पकड़ने की उम्मीद नहीं की जा सकती है: सभी निष्पादन पथों का मूल्यांकन करना असंभव है लेकिन सबसे छोटे कार्यक्रमों में। यूनिट परीक्षण के लिए भी यही सच है। इसके अतिरिक्त, परिभाषा द्वारा इकाई परीक्षण केवल इकाइयों की कार्यक्षमता का परीक्षण करता है। इसलिए, यह एकीकरण त्रुटियों या व्यापक सिस्टम-स्तरीय त्रुटियों (जैसे कई इकाइयों में किए गए कार्यों, या प्रदर्शन जैसे गैर-कार्यात्मक परीक्षण क्षेत्रों) को पकड़ नहीं पाएगा। यूनिट परीक्षण अन्य सॉफ्टवेयर परीक्षण गतिविधियों के संयोजन के साथ किया जाना चाहिए। सॉफ्टवेयर परीक्षण के सभी रूपों की तरह, यूनिट परीक्षण केवल त्रुटियों की उपस्थिति दिखा सकते हैं; वे त्रुटियों की अनुपस्थिति नहीं दिखा सकते हैं।
इकाई परीक्षण से इच्छित लाभ प्राप्त करने के लिए, सॉफ्टवेयर विकास प्रक्रिया में कठोर अनुशासन की आवश्यकता है। सावधान रिकॉर्ड रखने के लिए जरूरी है कि न केवल किए गए परीक्षणों में से, बल्कि सॉफ़्टवेयर में इस या किसी अन्य इकाई के स्रोत कोड में किए गए सभी परिवर्तनों के लिए भी आवश्यक है। एक संस्करण नियंत्रण प्रणाली का उपयोग आवश्यक है। यदि इकाई का बाद का संस्करण एक विशेष परीक्षण में विफल रहता है जिसे पहले पारित किया गया था, तो संस्करण-नियंत्रण सॉफ़्टवेयर स्रोत कोड परिवर्तनों (यदि कोई हो) की एक सूची प्रदान कर सकता है जो उस समय से इकाई पर लागू किया गया है।
यह सुनिश्चित करने के लिए टिकाऊ प्रक्रिया को लागू करना भी आवश्यक है कि टेस्ट केस विफलताओं की प्रतिदिन समीक्षा की जाए और तुरंत संबोधित किया जाए। यदि ऐसी प्रक्रिया को लागू नहीं किया गया है और टीम के वर्कफ़्लो में शामिल किया गया है, तो एप्लिकेशन यूनिट टेस्ट सूट के साथ सिंक से बाहर हो जाएगा, झूठी सकारात्मक वृद्धि और परीक्षण सूट की प्रभावशीलता को कम करेगा।
मुझे उम्मीद है कि अब आपको "यूनिट परीक्षण" शब्द की बेहतर समझ है। और आप जो करना चाहते हैं वह "सॉफ्टवेयर प्रोटोटाइप" से सीखना है। खैर, जहां तक सीखना चिंतित है आप किसी भी तरह से चुन सकते हैं यानी। ए) एक बी कोड करने से पहले बहुत से प्रोग्राम पढ़ें बी) बस किसी भी प्रोग्रामिंग भाषा की कुछ मूल बातें पढ़ें और सरल प्रोग्राम बनाने शुरू करें और बाद में उन्हें अपने बढ़े हुए ज्ञान के साथ जटिल बनाएं।
विकल्प (क) विशेषज्ञ के रास्ते पर आप प्राप्त करने के लिए कम समय लगता है और यह भी वहाँ गलत प्रथाओं है कि आप "स्व सीखने प्रोग्रामिंग 'के दौरान विकसित कर सकते हैं अपनाने के लिए एक कम मौका है
विकल्प (ख) अधिक समय लगता है आपको विशेषज्ञ के रास्ते पर लाने के लिए, लेकिन हो सकता है कि आप प्रोग्रामिंग की अपनी शैली तैयार कर सकें और हो सकता है कि यह प्रोग्रामिंग के अन्य विशेषज्ञ की शैली के रूप में अच्छा हो (चाहे बेहतर न हो)।
मुझे सलाह दी गई है कि उपर्युक्त विकल्पों (ए) या (बी) के केवल एक ही तरीके का चयन न करें। दोनों की एक मिक्स का उपयोग करें और विकल्प के साथ शुरू करें (ए)।
हैप्पी प्रोग्रामिंग!पागल समुदाय में आपका स्वागत है!
एक सॉफ्टवेयर इंजीनियरिंग दृष्टिकोण से में नीचे drilled? कंप्यूटर विज्ञान छात्र परिप्रेक्ष्य से? एक शौकिया परिप्रेक्ष्य से? – Alex
यूनिट परीक्षण! = टीडीडी। वे मेरे दिमाग में काफी अलग अवधारणाएं हैं। –
क्या आप शीर्षक या शरीर में सवाल पूछ रहे हैं? वे दो अलग-अलग चीजें हैं। –