आपके लिए इकाई परीक्षणों का क्या अर्थ है?

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

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


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

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

इन तर्कों के साथ बहस करना मुश्किल है, हालांकि, ये यूनिट परीक्षणों के केवल (और मेरे दृष्टिकोण से, मुख्य से दूर) फायदे से बहुत दूर हैं।

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

संपत्ति 1. इकाई परीक्षण प्रणाली के प्रतिरूपकता और डिजाइन को सकारात्मक रूप से प्रभावित करते हैं।

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

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

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

संपत्ति 2. यूनिट परीक्षण सिस्टम विनिर्देशों का एक उत्कृष्ट स्रोत हैं।

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

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

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

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

संपत्ति 4. यूनिट परीक्षण हमारे समय की बचत करते हैं।

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

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

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

निष्कर्ष

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

संबंधित लिंक

1. सेराडियो एपिसोड 167: द हिस्ट्री ऑफ ज्यूनिट एंड द फ्यूचर ऑफ टेस्टिंग विद केंट बेक

2. केंट बेक। विकास परीक्षण

ये केंट बेक की विशेषता वाले केवल दो अद्भुत पॉडकास्ट हैं, जिसमें वह विकास परीक्षण संस्कृति, ओ जुनीत, निरंतर परीक्षण, और बहुत कुछ के बारे में बात करते हैं। मैं इसकी अत्यधिक अनुशंसा करता हूं!