[java] यूनिट परीक्षण का बिंदु क्या है?


3 Answers

संक्षिप्त उत्तर: हाँ, आप घमंडी हैं। ;)

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

अब .... आप कैसे जानते हैं कि आपका कोड सही और सही है? आपको इसका परीक्षण करने की ज़रूरत है। यदि इसका परीक्षण नहीं किया गया है, तो आप भरोसा नहीं कर सकते कि यह काम करता है।

यह केवल प्रतिगमन के बारे में नहीं है (क्योंकि इसका तात्पर्य है कि कोड काम करने के लिए प्रयोग किया जाता है। क्या होगा यदि यह कभी काम नहीं करता? यह पहली बार लिखा गया था जब यह छोटी थी)

मैं समझता हूं कि स्वचालित परीक्षण का विचार प्रतिगमन को रोकने के लिए है, लेकिन मुझे नहीं पता कि यह पहली जगह में कैसे समस्या हो सकती है। मॉड्यूलर, ऑब्जेक्ट-ओरिएंटेड, संक्षिप्त कोड जो अच्छी तरह से टिप्पणी की जाती है उसे रिग्रेशन में कोई समस्या नहीं है।

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

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

आप पहली बार इसे कैसे बनाते हैं, यद्यपि? जैसा कि मैंने ऊपर कहा है, ऐसा करने के लिए, आपको यह दिखाने के लिए परीक्षण करना होगा कि कोड काम करता है । लेकिन सबसे महत्वपूर्ण बात यह है कि आप "डिजाइन" के लिए कैसे डिजाइन करते हैं जो भविष्य में जोड़े जाएंगे? आप यह भी नहीं जानते कि वे अभी तक क्या हैं।

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

नहीं, कदापि नहीं।

आपके कोड को निश्चित रूप से त्रुटि स्थितियों को संभालना चाहिए और यह निश्चित रूप से लॉग इन करना चाहिए कि आपको लॉग इन करने की आवश्यकता है।

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

किसी भी अनौपचारिक आवेदन के लिए, ऐसी कई चीजें हैं जो गलत हो सकती हैं। बहुत सारी कार्यक्षमता, बहुत सारे कोड और कई अलग-अलग निष्पादन पथ हैं।

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

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

Question

इस प्रश्न का उत्तर यहां दिया गया है:

मैंने हाल ही में एक टीम में प्रवेश किया है जो यूनिट परीक्षण का भारी उपयोग करता है। कोई भी मुझे समझा सकता है कि परीक्षण का यह रूप इतना महत्वपूर्ण क्यों है, लेकिन वे इसे कानून की तरह मानते हैं।

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

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

क्या मैं निष्कर्ष निकालने में घमंडी हूं कि यूनिट परीक्षण "खराब" कोडबेस के लिए एक क्रैच है जो त्रुटिपूर्ण और खराब तरीके से बनाया गया है?

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

संपादित करें: उत्तर के लिए धन्यवाद, मुझे लगता है कि मैं इसे समझ रहा हूं। मुझे लगता है कि कुछ लोगों को हटाने के लिए वोट दिया गया है, लेकिन मैं उन लोगों का शुक्रिया अदा करना चाहता हूं जिन्होंने उत्तर दिया; यह वास्तव में मदद की!




मैं समझता हूं कि स्वचालित परीक्षण का विचार प्रतिगमन को रोकने के लिए है, लेकिन मुझे नहीं पता कि यह पहली जगह में कैसे समस्या हो सकती है।

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

एक विशेष कारण: प्रोग्रामर एक ही तरह की सरल गलतियों को और अधिक बनाते हैं। उदाहरण के लिए: जब आपके देवताओं में से एक उस डेट हैंडलिंग कोड को फिर से फैक्टर कर रहा है, तो वह गलत धारणा जारी रखेगा कि उदाहरण के लिए फरवरी में हमेशा 2 9 दिन होते हैं, या इससे भी बदतर, कि सभी महीने एक ही लंबाई हैं।

इस तरह की चीज के खिलाफ रिग्रेशन परीक्षण आपकी एकमात्र रक्षा है।




मॉड्यूलर, ऑब्जेक्ट-ओरिएंटेड, संक्षिप्त कोड जो अच्छी तरह से टिप्पणी की जाती है उसे रिग्रेशन में कोई समस्या नहीं है।

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

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

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

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

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

त्रुटि प्रबंधन आपको बताता है कि कुछ गलत हो गया है। यूनिट परीक्षण आपको बता सकते हैं कि कहां है । आप केवल यह सुनिश्चित कर सकते हैं कि सब कुछ ठीक है क्योंकि यह आपके कोडबेस के साथ उचित परीक्षण के साथ होना चाहिए।

कोई भी obfuscated कोड लिख सकता है और आपको बता सकता है कि यह सकारात्मक रूप से सही है। कोड कोड विरासत में कोई भी व्यक्ति नहीं बता सकता है। यूनिट परीक्षण इस मुद्दे को कम करने में मदद करते हैं।

क्या मैं निष्कर्ष निकालने में घमंडी हूं कि यूनिट परीक्षण "खराब" कोडबेस के लिए एक क्रैच है जो त्रुटिपूर्ण और खराब तरीके से बनाया गया है?

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

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

यह भी मामला है कि एक बग को ठीक करने के लिए और अधिक महंगा हो जाता है, आगे बढ़ने वाली श्रृंखला को आगे बढ़ाया जाता है। सार्वजनिक रिलीज में मिलने वाली बग की तुलना में रिलीज उम्मीदवार में मिली बग की तुलना में क्यूए में मिली बग की तुलना में विकास में पाया गया एक बग कम महंगा है।

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




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

मैं समझता हूं कि स्वचालित परीक्षण का विचार प्रतिगमन को रोकने के लिए है, लेकिन मुझे नहीं पता कि यह पहली जगह में कैसे समस्या हो सकती है।

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

मॉड्यूलर, ऑब्जेक्ट-ओरिएंटेड, संक्षिप्त कोड जो अच्छी तरह से टिप्पणी की जाती है उसे रिग्रेशन में कोई समस्या नहीं है।

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

यदि आप यूनिट-परीक्षण को दस्तावेज़ व्यवहार के तरीके के रूप में देखते हैं, तो क्या यह पुराने कोड की कार्यक्षमता को संप्रेषित करने का एक समान या अधिक प्रभावी तरीका नहीं हो सकता है?

परीक्षण निश्चित रूप से दस्तावेज को कभी नहीं रोकना चाहिए, लेकिन प्रत्येक उपकरण के अपने पेशेवर और विपक्ष हैं।

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

मेरी राय में शुरुआत से सबकुछ सही और लचीला बनाने में लागत और प्रयास शामिल है और अक्सर दो चीजों में परिणाम होता है: एक अत्यधिक जटिल प्रणाली और धीमी गति से विकास की गति।

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

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

यदि आपके पास मौजूदा कार्यक्षमता पर परीक्षण हैं, तो कार्यक्षमता को विस्तारित करना आसान हो जाएगा?

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

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

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

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






Related



Tags

java java   testing