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