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



testing (9)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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


मेरे पास जोड़ने के लिए केवल दो और बिट हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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


जब आप पहली बार अपना कोड लिखना शुरू करते हैं तो ऐसा लगता है कि यह बहुत आसान है और स्वचालित परीक्षणों की आवश्यकता नहीं है।

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

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


मैं वही बात अपने प्रोफेसर से पूछता हूं, और लंबे समय से सलाहकार, जो इसके द्वारा कसम खाता है, उन लोगों में से एक जो उन्होंने उल्लेख किया है या यहां उल्लेख किया जा रहा है यह है:

उन्होंने कहा कि परीक्षण आपके कोड को दस्तावेज करने का एक शानदार तरीका हो सकता है, यदि आप यह देखना चाहते हैं कि कोड को परीक्षणों पर कैसे व्यवहार करना चाहिए, तो यह आपको एक जटिलता बताएगा कि इसकी जटिलताओं को समझने के बिना क्या करने की कोशिश कर रहा है, और साथ ही आप यह जांच सकते हैं कि यह वास्तव में ऐसा कर रहा है, तो यह एक जीत जीत ... :)

हालांकि मुझे एक एहसास है कि उसने अभी कहा था कि चूंकि वह जानता था कि मुझे टिप्पणी कोड पसंद नहीं है लेकिन स्वयं दस्तावेज स्रोत कोड पसंद करते हैं, फिर भी दिलचस्प दृष्टिकोण का प्रकार;)

एक साइड नोट के रूप में आपको coverage पर एक नज़र डालना चाहिए, जब आप यूनिट टेस्ट या डिज़ाइन टेस्ट सूट करते हैं तो आप कवरेज चाहते हैं कि 100% जितना संभव हो सके कवर करें कि परीक्षणों ने आपके कोड का 100% परीक्षण किया है, जिसमें सभी शामिल हैं यह अलग-अलग पथ ले सकते हैं, यह काफी चुनौतीपूर्ण है, और आपके परीक्षण कोड को आपके स्रोत से कई गुना बड़ा कर सकता है, हालांकि आप अपने टेस्ट कोड को स्वचालित भी कर सकते हैं, एक साधारण उदाहरण एसक्यूएल डेटाबेस का परीक्षण करेगा, आप एक प्रोग्राम बना सकते हैं जो उत्पन्न करता है सभी संभावित एसक्यूएल स्टेटमेंट्स और टेस्ट वे ठीक तरह से निष्पादित होते हैं, मुझे लगता है कि एसक्लाइट 3 में 91 मिलियन से अधिक परीक्षण परीक्षण हैं, http://www.sqlite.org/testing.html बहुत रोचक ... ओह यह he भी वकालत करता है।


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

base_dir=$(pwd)                                                                  
src_dir=$base_dir/src/main/java                                                  
ic_api_cp=$base_dir/target/classes                                               

while read f                                                                     
do                                                                               
    clazz=${f//\//.}                                                             
    clazz=${clazz/%.java/}                                                       
    seruidstr=$(serialver -classpath $ic_api_cp $clazz | cut -d ':' -f 2 | sed -e 's/^\s\+//')
    perl -ni.bak -e "print $_; printf qq{%s\n}, q{    private $seruidstr} if /public class/" $src_dir/$f
done

आप इस स्क्रिप्ट को सहेजते हैं, add_serialVersionUID.sh आपको ~ / bin पर कहते हैं। फिर आप इसे अपने मेवेन या ग्रैडल प्रोजेक्ट की मूल निर्देशिका में चलाते हैं जैसे:

add_serialVersionUID.sh < myJavaToAmend.lst

इस .lst में निम्न प्रारूप में serialVersionUID जोड़ने के लिए जावा फ़ाइलों की सूची शामिल है:

com/abc/ic/api/model/domain/item/BizOrderTransDO.java
com/abc/ic/api/model/domain/item/CardPassFeature.java
com/abc/ic/api/model/domain/item/CategoryFeature.java
com/abc/ic/api/model/domain/item/GoodsFeature.java
com/abc/ic/api/model/domain/item/ItemFeature.java
com/abc/ic/api/model/domain/item/ItemPicUrls.java
com/abc/ic/api/model/domain/item/ItemSkuDO.java
com/abc/ic/api/model/domain/serve/ServeCategoryFeature.java
com/abc/ic/api/model/domain/serve/ServeFeature.java
com/abc/ic/api/model/param/depot/DepotItemDTO.java
com/abc/ic/api/model/param/depot/DepotItemQueryDTO.java
com/abc/ic/api/model/param/depot/InDepotDTO.java
com/abc/ic/api/model/param/depot/OutDepotDTO.java

यह स्क्रिप्ट हुड के तहत जेडीके धारावाहिक उपकरण का उपयोग करती है। तो सुनिश्चित करें कि आपका $ JAVA_HOME / bin पाथ में है।





java testing