क्या हमें TDD करते समय लॉगिंग की आवश्यकता है?

Question

Red, Green & Refactor चक्र को करते समय हमें टेस्ट पास करने के लिए हमेशा न्यूनतम कोड लिखना चाहिए। यह वही तरीका है जो मुझे टीडीडी के बारे में पढ़ाया गया है और जिस तरह से लगभग सभी किताबें प्रक्रिया का वर्णन करती हैं।

लेकिन लॉगिंग के बारे में क्या?

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

तो मेरे सवाल हैं:

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

क्या मुझे कुछ याद आ रहा है?

Comments

मुझे लगता है कि इतने सारे नियमों के लिए लॉगिंग विशेष मामला है। एक क्लास / फंक्शन में एक काम करना चाहिए और एक ही काम करना चाहिए ... सिवाय लॉगिंग के। कार्य लॉगिंग को छोड़कर अधिमानतः शुद्ध होना चाहिए। इसी तरह आगे भी। लॉगिंग नियम तोड़ता है।

— फोशी

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

— हाइड

Answer 1

1) क्या हमें लॉग इन करने की जरूरत है अगर हम टीडीडी कर रहे हैं? असफल परीक्षा से पता नहीं चलेगा कि आवेदन में क्या गलत है?

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

2) क्या हमें प्रत्येक कक्षा में प्रत्येक विधि में लॉगिंग प्रक्रिया के लिए परीक्षण जोड़ना चाहिए?

यदि लकड़हारे का स्वयं परीक्षण किया जाता है, तो उसे अन्य निर्भरता के समान, प्रत्येक कक्षा में सेवानिवृत्त होने की आवश्यकता नहीं होगी।

3) उदाहरण के लिए यदि उत्पादन वातावरण में कुछ लॉग स्तर अक्षम हैं, तो क्या यह परीक्षण और पर्यावरण के बीच निर्भरता का परिचय नहीं देगा?

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

"रेल्स लॉग स्तर उत्पादन मोड और विकास और परीक्षण में डिबग की जानकारी है" - http://guides.rubyonrails.org/debugging_rails_applications.html

अन्य एप्लिकेशन एक समान दृष्टिकोण का उपयोग करते हैं।

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

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

Comments

यहां तक ​​कि सही ढंग से निष्पादित टीडीडी भी प्रदर्शन, सिस्टम इंटरैक्शन, थर्ड-पार्टी इंटरैक्शन के साथ उत्पादन की समस्याओं को नहीं रोकेगा। समसामयिक मुद्दे भी पूरी तरह से परीक्षण द्वारा कवर करने के लिए बहुत कठिन हैं। 100% परीक्षण कवरेज "केवल" का अर्थ है कि आपके कोड का 100% निष्पादित किया गया है, न कि सभी राज्यों या वातावरणों में सही है।

— होलस्टेब्रो

Answer 2

किसी अनुप्रयोग के गैर-असाधारण व्यवहार की व्याख्या करने के लिए लॉगिंग उपयोगी है :

सिस्टम लॉग एक ऑडिट ट्रेल प्रदान करने के लिए सिस्टम के निष्पादन में हो रही घटनाओं को रिकॉर्ड करता है जिसका उपयोग सिस्टम की गतिविधि को समझने और समस्याओं का निदान करने के लिए किया जा सकता है। वे जटिल प्रणालियों की गतिविधियों को समझने के लिए आवश्यक हैं, विशेष रूप से छोटे उपयोगकर्ता इंटरैक्शन (जैसे सर्वर एप्लिकेशन) के साथ अनुप्रयोगों के मामले में ...

कोई फर्क नहीं पड़ता कि आवेदन का परीक्षण किया गया था और कोई फर्क नहीं पड़ता कि अपवादों को कितनी अच्छी तरह से लॉग किया गया है, इसके उपयोगकर्ता पूछ सकते हैं,

आपके कार्यक्रम का आउटपुट 0 है जबकि हमें उम्मीद थी कि यह 1 होगा, ऐसा क्यों है?

आपको यह सत्यापित करने के लिए लॉगिंग की आवश्यकता है कि उसके (गैर-असाधारण) व्यवहार की व्याख्या करने के लिए एप्लिकेशन कॉन्फ़िगरेशन, पैरामीटर और अन्य रनटाइम विवरण क्या थे।

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

लॉगिंग क्या एप्लिकेशन को अनुमति देता है कि कोई और कोड में खुदाई के बिना और बिना क्या चल रहा है, यह समझाने के लिए डेवलपर्स को विचलित किए बिना प्रोग्राम के व्यवहार की अनुमति देता है ।

Comments

+1 के लिए "लॉगिंग समर्थन पर अधिक उन्मुख है"। सच में सिर पर कील ठोक दी।

— टिबोस

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

— लॉग

@logc के स्रोत को पहले ही शब्द "लॉगिंग" में लिंक द्वारा संदर्भित किया गया है, "लॉगिंग" - यदि आप इसे क्लिक करते हैं, तो आप इसे विकिपीडिया लेख पर लाएंगे: en.wikipedia.org/wiki/Logfile

— gnat #

Answer 3

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

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

Comments

ऑडिट ट्रेल उद्देश्यों के लिए लॉगिंग के बारे में भी मत भूलना। या बिलिंग। या विभिन्न प्रकार के आँकड़े। या अन्य प्रणालियों के अन्य प्रकार के आंकड़ों के साथ मिलान के लिए इवेंट लॉगिंग।

— प्लाज़्मा एचएच

क्या कुछ ऐसा नहीं है जिसे आप लॉगिंग के बिना करते हैं? या क्या आप अभी मतलब है कि आप लगातार प्रोफाइलिंग परिणाम लॉग कर सकते हैं?

— बरगी

@ बर्गी: पूरी तरह से इस बात पर निर्भर करता है कि आपका आवेदन कैसे काम करता है। यदि इसका उदाहरण वेबपीलेशन है तो प्रत्येक अनुरोध के सेवा समय को लॉग करना, और फिर बाद में "खराब प्रदर्शन करने वालों" के लिए उन घटनाओं को क्लस्टर करने की कोशिश करना भी काम कर सकता है।

— प्लाज्माएच

@Bergi प्रोफाइलिंग डेवलपमेंट में होती है, लेकिन लाइव सिस्टम पर इ-इफेक्ट्स का ध्यान रखा जाता है। ई-डिस्क का उपयोग धीमा हो सकता है, CPU अधिक लोड हो सकता है, सेवाएं समय पर प्रतिक्रिया नहीं दे सकती हैं, समानांतर थ्रेड लॉकिंग मुद्दों में चल सकते हैं ...

— जोहान्स

@PlasmaHH ऑडिटिंग मुख्य आवश्यकताओं का हिस्सा है और इसे परीक्षणों द्वारा कवर किया जाना है। ज्यादातर मामलों में मैं इसे "सामान्य" लॉगिंग मार्गों पर नहीं चलाता। सामान्य लॉगिंग विफल हो सकती है, ऑडिटिंग नहीं। "विभिन्न आँकड़े" मैं प्रदर्शन के तहत एकत्र हुए;)

— जोहान्स

Answer 4

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

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

लॉगिंग और टीडीडी विभिन्न चिंताओं को संबोधित करते हैं।

Answer 5

1. जब तक आपके पास 100% परीक्षण कवर नहीं होता है, जो आमतौर पर ऐसा नहीं होता है, तो आप यह नहीं जान सकते कि आपका सॉफ़्टवेयर कभी भी क्रैश नहीं होगा (EDIT: और - जैसा कि टिप्पणियों में कहा गया है - भले ही ऐसा हो, आपके सॉफ़्टवेयर से स्वतंत्र कुछ कारण हो सकता है एक दुर्घटना); यह सोच के समान है कि आप एक ऐसा सॉफ्टवेयर कर सकते हैं जिसमें कोई बग न हो (नासा भी ऐसा नहीं कर सकता)। तो बहुत कम से कम, आपको अपने प्रोग्राम के क्रैश होने की स्थिति में संभावित विफलताओं को लॉग इन करना होगा ताकि आप जान सकें कि क्यों।

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

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

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

Comments

यहां तक ​​कि अगर आपके पास 100% कवरेज है, तो क्या आपके पास हर संभव चीज के लिए यह हो सकता है? यदि आपके डेटाबेस का नेटवर्क कनेक्शन नीचे चला जाए तो क्या होगा? क्या आपके परीक्षण आपको बताएंगे?

— जाकारी कश्मीर

आप कभी नहीं जान सकते हैं कि आपका सॉफ्टवेयर 100% कवरेज होने पर कभी भी EVEN को क्रैश नहीं करेगा। 100% कवरेज, जबकि वांछनीय, यह प्रतीत होता है की तुलना में शुद्धता के बारे में बहुत कम जानकारी देता है।

— एंड्रेस एफ।

हां, आप इसके बारे में भी सही हैं। मुद्दा यह है कि दुर्घटना की कोई संभावना नहीं है। मैं संपादित करूँगा।

— पियरे अरलाउड

संपादन अभी भी गलत है। यहां तक ​​कि अगर आपके पास 100% परीक्षण कवरेज है, तो आपके कोड में एक बग हो सकता है (बाहरी कारणों को दोष देने की आवश्यकता नहीं है)। टेस्ट आपके कोड काम का मतलब नहीं है; केवल एक चीज जो वे किसी निश्चितता के साथ करते हैं वह यह है कि आप एक परीक्षण लिखने में विफल रहे जो बग ढूंढता है :) टेस्ट कवरेज एक महत्वपूर्ण मीट्रिक है, लेकिन सीधे बग की अनुपस्थिति से संबंधित नहीं है।

— एंड्रेस एफ।

यह साबित करने के लिए तुच्छ है कि "100% परीक्षण कवरेज जो गुजरता है! = बग मुक्त"। प्रतिधारण: add(x, y) = 2(हमेशा 2 रिटर्न)। निम्नलिखित परीक्षण गुजरता है और पूर्ण कवरेज प्रदान करता है assert(2 == add(1,1)):। एक छोटी गाड़ी समारोह के लिए 100% परीक्षण कवरेज :)

— एन्ड्रेस एफ।

Answer 6

हां, सामान्य मामले में आपको लॉगिंग की आवश्यकता है।

लॉगिंग डीबगिंग के बारे में नहीं है। ठीक है, ठीक है, लॉगिंग का एक हिस्सा कभी-कभी डिबगिंग के बारे में होता है, और यदि विकास के दौरान आपको इसकी आवश्यकता नहीं है, तो आप उस हिस्से को छोड़ सकते हैं।

लेकिन लॉगिंग का अधिक महत्वपूर्ण हिस्सा रखरखाव के बारे में है। अच्छी तरह से डिज़ाइन की गई लॉगिंग निम्नलिखित प्रश्नों का उत्तर दे सकती है:

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

यह सब लॉग इन करके हासिल किया जा सकता है। और हां, यह योजनाबद्ध और डिजाइन और परीक्षण किया जाना चाहिए, बेहतर स्वचालित।

लॉगिंग एक ऐसी सुविधा है जो अन्य सुविधाओं की तरह ही उपचार को पूरा करती है।

Answer 7

TL; DR: लॉगिंग और TDD ऑर्थोगोनल हैं। एक के होने से दूसरे पर कोई असर नहीं पड़ता

अगर हम TDD कर रहे हैं तो क्या हमें लॉग इन करने की आवश्यकता है? असफल परीक्षा से पता नहीं चलेगा कि आवेदन में क्या गलत है?

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

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

क्या हमें प्रत्येक कक्षा में प्रत्येक विधि में लॉगिंग प्रक्रिया के लिए परीक्षण जोड़ना चाहिए?

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

यदि उत्पादन के वातावरण में कुछ लॉग स्तर अक्षम हैं, तो क्या यह परीक्षण और पर्यावरण के बीच निर्भरता का परिचय नहीं देगा?

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

Answer 8

टीडीडी आमतौर पर कोडिंग बग्स को कम करने में मदद करता है। यह विनिर्देशन के साथ बग के साथ बहुत कम मदद करता है या सिर्फ गलतफहमी है कि चीजें कैसे काम करती हैं।

"ओह? आप एक डेटा संदेश प्राप्त कर सकते हैं इससे पहले कि आप पुष्टि करें कि लॉगऑन सफल हो गया? मुझे कभी नहीं पता था, अच्छी तरह से यह संभाल नहीं करेगा!" ... इस तरह की बात। लॉगिंग आपको यह बताने के लिए बहुत उपयोगी है कि सॉफ़्टवेयर ने ऐसा करने की कोशिश की थी जिससे आप उस चीज़ को देख सकते हैं जो आपने गलत किया था।

Answer 9

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

जबकि टीडीडी (या शायद टेस्ट-जब भी) कर रहा हूं तो मैं खुद को बहुत कम लॉग स्टेटमेंट जोड़ पाता हूं। यह बदले में कम LOC का मतलब है और प्रदर्शन को प्रभावित कर सकता है (हमेशा नहीं)।

लेकिन हम विकास पद्धति की परवाह किए बिना ज्यादातर मामलों में मेरी कंपनी में अर्ध-स्वचालित तरीके से कार्यों के लिए प्रवेश-निकास लॉग जोड़ते हैं। जैसा कि मैं जानता हूं कि इसे उत्पादन के मुद्दे के विश्लेषण के लिए अनिवार्य माना गया था।

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

Comments

क्या आप उन कारणों पर विस्तार कर सकते हैं जिनमें आप फ़ंक्शंस के लिए प्रवेश-निकास लॉग क्यों जोड़ते हैं? आपकी कंपनी में इसकी आवश्यकता क्यों है?

— कुटकी

हाँ बिल्कुल। मुझे उम्मीद है कि अब यह बेहतर है।

— डबलाकिरेव