मैं थोड़ा उलझन में हूं कि डीबग या यूनिट टेस्ट लिखने के लिए बेहतर क्या है? और क्या यह सामान्य है या ऐसे मामले हैं जहां इकाई परीक्षण से बेहतर डीबग हो? या क्या मुझे उन दोनों का उपयोग करना चाहिए?डीबग बनाम यूनिट परीक्षणों का उपयोग कब करें?
धन्यवाद
डीबगिंग आपको गैर-कार्यशील कोड का निदान करने में मदद करेगा।
ईकाई परीक्षण निम्नलिखित प्रदान करते हैं। वे आपको विश्वास के साथ अपने कोड को दोबारा करने की अनुमति देंगे कि यह अभी भी काम करता है।
आपके यूनिट परीक्षण बार-बार चलने चाहिए (अक्सर आपकी बिल्ड प्रक्रिया के हिस्से के रूप में)। यदि आप उन्हें तोड़ते हैं (अक्सर प्रोग्रामिंग त्रुटि के कारण), फिर समस्या का पता लगाने के लिए डीबगर को तोड़ने और कोड को ठीक करने (या शायद परीक्षण में संशोधन) करने का समय है।
आप इकाई परीक्षण में बग प्रजनन करने में सक्षम हैं, तो एक इकाई परीक्षण का उपयोग करें। यह बग हल हो जाने के बाद और भविष्य में कोड को "सुरक्षा" के बाद रखेगा।
यदि आपको अपमानजनक कोड का टुकड़ा खोजने में कठिनाई है, तो डिबगिंग शायद एक बेहतर समाधान है। लेकिन, जिस क्षण आप जानते हैं कि समस्या कहां है - एक परीक्षा लिखें, सुनिश्चित करें कि यह विफल हो जाता है और फिर बग ठीक कर देता है।
डिबगिंग में अधिक समय लगता है और यह एक "एक बार" समाधान है। जब आपके पास यूनिट-टेस्ट का विकल्प होता है, तो यूनिट-टेस्ट पसंद करते हैं।
यूनिट परीक्षण का उपयोग यह सुनिश्चित करने के लिए किया जाता है कि कोड अपेक्षा के अनुसार काम करता है। डीबग का उपयोग तब किया जाता है जब आपको यह पता लगाना पड़ता है कि कोड अपेक्षित रूप से क्यों काम नहीं करता है।
+1 दोहराएं, यूनिट-परीक्षण सिर्फ सिस्टम को निष्पादित करता है (वास्तव में मैं परीक्षण-केस चलाने के दौरान कोड डीबग करता हूं)। यह केवल इतना है कि आप यूनिट-टेस्ट के साथ कम दोष पैदा करते हैं, इसलिए कुल मिलाकर आपको कम दोषों को ठीक करने की आवश्यकता होती है। –
यूनिट परीक्षणों को डिबगिंग और लिखना दो अलग-अलग चीजें हैं। सिद्धांत रूप में आपके विकास को विभिन्न परिदृश्यों को कवर करने वाले यूनिट परीक्षणों द्वारा संचालित किया जाना चाहिए। जब आप महसूस करते हैं कि आपके कोड में कुछ गड़बड़ है और रनटाइम में विभिन्न चर के मानों को देखने का प्रयास करें, तो आप डीबग कर सकते हैं ... तो मूल रूप से आप कुछ गलत होने पर ही डीबग कर सकते हैं।
एक और परिप्रेक्ष्य:
हमेशा सब कुछ है कि आप कर सकते हैं इकाई परीक्षण करते हैं। आदर्श अलगाव में प्रत्येक घटक का परीक्षण करता है, फिर सहयोग करने वाले घटकों के एकीकरण परीक्षण करता है।
आप किस बारे में बात कर रहे हैं यह एक अलग सवाल है हालांकि: अगर कुछ तोड़ता है, तो आपको क्या करना चाहिए, यूनिट परीक्षण को लिखने और लिखने के लिए डीबगर चलाएं। ये वास्तव में विकल्प नहीं हैं। अगर कुछ तोड़ता है और आप इकाई परीक्षण में व्यवहार देख सकते हैं, तो यह आदर्श है। लेकिन आपको अभी भी व्यवहार का कारण खोजना है। अब आपके विकल्प लॉगिंग जोड़ने और डीबगर चलाने के बीच हैं, और मैं उन लोगों के साथ वोट देता हूं जो लॉगिंग का उपयोग करते हैं जब तक आप नहीं कर सकते।डीबगर समय कोड को कोई दीर्घकालिक मूल्य नहीं जोड़ता है। लॉगिंग करता है।
मुझे लगता है कि कुछ प्रश्नों के मुकाबले इस सवाल को गहन तरीके से देखा जा सकता है ... हालांकि प्रोग्रामिंग स्टैक एक्सचेंज के लिए बेहतर फिट हो सकता है।
पहले कैसे डिबगिंग और इकाई परीक्षण बातचीत
जब कुछ आपकी समस्या को डिबग एक दृष्टिकोण रोक डिबगिंग के लिए है और इकाई शुरू करने के लिए पर्याप्त रूप से कठिन है पर कुछ टिप्पणियां इसी तरह के समस्याग्रस्त इनपुट का उपयोग कर संबंधित चीजों का परीक्षण। आप उस इनपुट को सरल बनाने की कोशिश कर सकते हैं जो पहले समस्याओं का कारण बनता है (मान लीजिए कि आपका सिस्टम निर्धारक है!)
उपरोक्त उपरोक्त बिंदु के समान आप सिस्टम के माध्यम से अपने समस्याग्रस्त कोड का पता लगा सकते हैं और कॉल श्रृंखला को कम करने वाली चीज़ों को अनदेखा करना शुरू कर सकते हैं समान इनपुट के साथ
इकाई परीक्षण, "समय से आगे डिबगिंग" या "निराशावादी डिबगिंग" के रूप में माना जा सकता है यह सोचते हैं आप इसे सीधे डिबग करने के लिए इतनी कोशिश कर एक बग के लिए जा रहे हैं। यदि आप इसे वास्तविक समस्या में रखते समय ऐसा कर रहे हैं, तो यह अनुमान लगाने की तरह है कि कोड के किसी विशेष अनुभाग में एक बग है और आप इसे टूटे हुए इनपुट पर अनुमान लगाकर प्राप्त कर सकते हैं।
दोष समाधान के लिए एक अच्छा प्रवाह: ग्राहक समस्या के बारे में शिकायत करता है => दोष को बग ट्रैकर => dev डीबग में जोड़ा जाता है और पुन: उत्पन्न करता है => dev यूनिट टेस्ट लिखता है जो पुन: उत्पन्न करता है => dev fixes bug => dev सभी यूनिट परीक्षणों को चलाने के लिए चलाता है निश्चित फिक्स कुछ और नहीं तोड़ दिया => (कुछ दोषों के लिए दोहराएं) => रिलीज => –