यूनिट टेस्ट परिभाषा;

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



लेकिन कुछ लोग जानते हैं कि कुछ दिनों पहले उसी मार्टिन फॉलर ने यूनिट टेस्ट ( ब्लिकी: यूनिटटेस्ट ) की परिभाषा देने की कोशिश की थी, जिसका अनुवाद नीचे प्रस्तुत किया गया है। और अनुवाद के बाद, इस विषय पर मेरे कुछ विचार हैं।



-

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







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



XP में इकाई परीक्षणों की भूमिका शुरू से ही कुछ चिंता का कारण रही। मुझे स्पष्ट रूप से यूनेट समूह में चर्चा याद है जिसमें परीक्षण विशेषज्ञ ने "यूनिट टेस्ट" शब्द का दुरुपयोग करने के लिए एक्सपी समर्थकों को डांटा था। हमने उनकी परिभाषा पूछी, जिसके लिए उन्होंने कुछ इस तरह जवाब दिया: "मेरे परीक्षण पाठ्यक्रम की शुरुआत में, मैं इकाई परीक्षण की 24 विभिन्न परिभाषाओं पर विचार करता हूं।"



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

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

इन्सुलेशन

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







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

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



जब 2000 के दशक में हुनिट परीक्षण को लोकप्रियता मिलनी शुरू हुई, तो अलगाव का विचार नए जोश के साथ लौटा, कम से कम कुछ के लिए। हमने मॉकिंग का समर्थन करने के लिए मॉक ऑब्जेक्ट्स और फ्रेमवर्क का उदय देखा है। नतीजतन, xunit परीक्षकों के दो स्कूल थे, जिन्हें मैं शास्त्रीय स्कूल और मॉकिस्ट स्कूल कहता हूं । शास्त्रीय स्कूल के अनुयायी अलगाव के साथ परेशान नहीं होते हैं, जैसा कि मोकिस्ट करते हैं। मैं दोनों स्कूलों के हुनिट परीक्षकों को जानता हूं और उनका सम्मान करता हूं (हालांकि मैं खुद शास्त्रीय विद्यालय का हूं)।



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

गति

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



अनुवादक का नोट

केंट बेक ने संकलन के दौरान परीक्षण चलाने का विचार विकसित किया (और कभी-कभी इसके बिना भी) और निरंतर परीक्षण (निरंतर परीक्षण) के विचार का प्रस्ताव दिया। ऐसे उपकरणों के उदाहरण: .NET के लिए माइटी-मूस और NCrunch , जावा के लिए JUnit मैक्स ।



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



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



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

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

नोट

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



(**) यदि आपके पास उपयोगी परीक्षण हैं, तो निष्पादन का समय प्रतिबद्ध परीक्षणों की अवधि से अधिक है, तो आपको " परिनियोजन पाइपलाइन " बनाने और इन परीक्षणों को पाइपलाइन के बाद के चरणों में रखने की आवश्यकता है।



-



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



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



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



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

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



क्लासिक्स या मोकिस्ट्स: दोनों शिविरों में से किसी एक पर चिपकना बिल्कुल सामान्य है। मुख्य बात यह है कि आपकी पसंद सचेत है, और आपके परीक्षण विकास और रखरखाव को सरल करते हैं, और इसके साथ हस्तक्षेप नहीं करते हैं।