unit testing - क्या यूनिट परीक्षण प्रयास के लायक है?




unit-testing (20)

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

https://code.i-harness.com


thetalkingwalnut पूछता है:

यूनिट परीक्षण के मूल्य की टीम पर संदेहजनक डेवलपर्स को मनाने के कुछ अच्छे तरीके क्या हैं?

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

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

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

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

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

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

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

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

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

इससे भी बदतर, शायद सॉफ्टवेयर विकास में एकमात्र निश्चितता यह है कि "परिवर्तन अपरिहार्य है"। सख्त दुकान (9 0% यूनिट परीक्षण / 10% उत्पादन कोड) मान लें कि एक उत्पाद बनाता है जिसमें वास्तव में 2 विशेषताएं हैं (उत्पादन कोड == 1 सुविधा का 5% मानते हैं)। यदि ग्राहक साथ आता है और सुविधाओं में से 1 को बदलता है, तो वह परिवर्तन 50% कोड (यूनिट परीक्षणों का 45% और उत्पादन कोड का 5%) को ट्रैश करता है। लक्स शॉप (10% यूनिट टेस्ट / 90% उत्पादन कोड) में 18 फीचर्स वाला उत्पाद है, जिनमें से कोई भी बहुत अच्छा काम नहीं करता है। उनके ग्राहक अपनी विशेषताओं में से 4 के लिए आवश्यकताओं को पूरी तरह से संशोधित करते हैं। भले ही परिवर्तन 4 गुना बड़ा हो, भले ही कोड आधार का आधा हिस्सा ट्रैश हो जाए (~ 25% = ~ 4.4% इकाई परीक्षण + उत्पादन कोड का 20%)।

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


[मेरे पास यह मुद्दा है कि मैं ऊपर नहीं देख सकता]

"हर इकाई परीक्षण, वे जरूरी नहीं समझते हैं - तथ्य"

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

वह यूनिट परीक्षण है - बुनियादी और बुरी तरह से एक साथ रखा गया है लेकिन आप कुछ मामलों के लिए कोड के टुकड़े का परीक्षण करते हैं।

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

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


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

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

प्रत्येक बार जब आप रिपोजिटरी से अपडेट करते हैं तो नई सुविधाओं के कारण टूटा हुआ परीक्षण अपडेट करने में घंटों खर्च करना न तो उत्पादक और न ही मजेदार है।


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


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


टेस्ट-संचालित विकास का एक बड़ा हिस्सा जो अक्सर चमकदार होता है वह टेस्टेबल कोड का लेखन होता है। ऐसा लगता है कि पहले किसी तरह का समझौता हुआ है, लेकिन आप पाएंगे कि टेस्टेबल कोड अंततः मॉड्यूलर, रखरखाव और पठनीय भी है। यदि आपको अभी भी लोगों को विश्वास दिलाने में मदद की ज़रूरत है तो this यूनिट परीक्षण के फायदों के बारे में एक अच्छी सरल प्रस्तुति है।


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


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

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


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


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

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

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


मैंने विषय के बारे में एक बहुत बड़ा ब्लॉग पोस्ट लिखा था। मैंने पाया है कि अकेले यूनिट परीक्षण काम के लायक नहीं है और आमतौर पर समय सीमा समाप्त होने पर कटौती हो जाती है।

"परीक्षण-बाद" सत्यापन बिंदु दृश्य से यूनिट परीक्षण के बारे में बात करने के बजाय, जब आप कार्यान्वयन से पहले एक spec / test / idea लिखने के लिए सेट करते हैं तो हमें उस वास्तविक मूल्य को देखना चाहिए।

इस सरल विचार ने सॉफ्टवेयर लिखने के तरीके को बदल दिया है और मैं "पुराने" तरीके से वापस नहीं जाऊंगा।

परीक्षण के पहले विकास ने मेरी जिंदगी कैसे बदल दी


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

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

और बड़ा एक ...

  • आपको यूनिट परीक्षण की आवश्यकता नहीं हो सकती है, लेकिन जब कोई और पूर्ण समझ के बिना कोड को संशोधित करता है और संशोधित करता है तो वह बहुत सी मूर्ख गलतियों को पकड़ सकता है।

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

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

मेरे दिमाग में इसका क्लासिक उदाहरण एक SqlDataReader है जो एक ग्रिड व्यू से जुड़े एएसपीएक्स पेज में एम्बेडेड है। कोड एएसपीएक्स फ़ाइल में सब कुछ है। एसक्यूएल एक संग्रहीत प्रक्रिया में है। आप यूनिट परीक्षण क्या करते हैं? यदि पृष्ठ ऐसा करता है जो इसे करना है, तो क्या आपको वास्तव में इसे कई परतों में फिर से डिजाइन करना चाहिए ताकि आपके पास स्वचालित करने के लिए कुछ हो?


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


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

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

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

सलाह का एक आखिरी टुकड़ा न केवल आपके कोड का परीक्षण करेगा, बल्कि पहले परीक्षण करना शुरू करें (अधिक के लिए TDD और BDD देखें)


यूनिट परीक्षण निश्चित रूप से प्रयास के लायक है। दुर्भाग्यवश आपने इसे एक कठिन (लेकिन दुर्भाग्य से सामान्य) परिदृश्य चुना है जिसमें इसे लागू करना है।

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

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


यूनिट-परीक्षण प्रारंभिक निवेश के लायक है। कुछ साल पहले यूनिट-परीक्षण का उपयोग शुरू करने के बाद से, मुझे कुछ वास्तविक लाभ मिले हैं:

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

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


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

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

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

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

परिवर्तन रात में नहीं होगा, लेकिन थोड़ा धैर्य के साथ, आप अपना लक्ष्य प्राप्त कर सकते हैं।


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

नए ढांचे या कोडबेस की खोज करते समय मेरी पसंदीदा चालों में से एक यह है कि चीजें कैसे काम करती हैं, यह जानने के लिए 'इसे' के लिए यूनिट-टेस्ट लिखना है। सूखे डॉक्टर को पढ़ने के बजाय कुछ नया सीखने का यह एक शानदार तरीका है :)


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

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

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

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

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





unit-testing