क्या हमें कोड कवरेज विश्लेषण के लिए कोड को बाहर करना चाहिए?


15

मैं कई अनुप्रयोगों पर काम कर रहा हूं, मुख्य रूप से विरासत वाले। वर्तमान में, उनका कोड कवरेज काफी कम है: आम तौर पर 10 और 50% के बीच।

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

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

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

इस दृष्टिकोण की रुचि यह है कि हमारे पास एक कोड कवरेज माप होगा जो उस एप्लिकेशन के भाग की वर्तमान स्थिति को इंगित करता है जिसे हम परीक्षण योग्य मानते हैं ।

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

इसके अलावा, हम ठीक से नहीं जान पाएंगे कि कोड कवरेज उपाय में क्या माना जाता है। उदाहरण के लिए, यदि मेरे पास ४०% कोड कवरेज के साथ १०,००० लाइनों का कोड है, तो मैं यह कटौती कर सकता हूं कि मेरे कोड आधार का ४०% परीक्षण किया गया है (२) । लेकिन क्या होगा अगर हम बहिष्करण निर्धारित करते हैं? यदि कोड कवरेज अब 60% है, तो मैं वास्तव में क्या कटौती कर सकता हूं? मेरे "महत्वपूर्ण" कोड आधार का 60% परीक्षण किया गया है? मैं कैसे कर सकता हूँ

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

उस विषय पर आपकी क्या राय है? आप अपनी परियोजनाओं पर कैसे काम करते हैं?

धन्यवाद।

(1) ये परतें सामान्यतः UI / जावा बीन्स इत्यादि से संबंधित होती हैं।

(२) मुझे पता है कि यह सच नहीं है। वास्तव में, इसका मतलब केवल यह है कि मेरे कोड का 40% आधार


क्या वे एक विशिष्ट कवरेज के खिलाफ अनुबंधित हैं?
जे.के.

जवाबों:


3

मैं आमतौर पर ऑटो-जनरेट कोड को बाहर करता हूं, जैसे कि WCF क्लाइंट जो विजुअल स्टूडियो उत्पन्न करता है। आमतौर पर कोड की बहुत सारी लाइनें होती हैं और हम कभी भी उनका परीक्षण नहीं करते हैं। यह कहीं और कोड के एक बड़े हिस्से पर परीक्षण बढ़ाने के लिए बहुत ही मनोबल प्रदान करता है और केवल 0.1% से कोड कवरेज बढ़ाता है।

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

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


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

मेरा मतलब है कि इकाई परीक्षण के लिए त्रुटि से निपटने, जैसे ... परीक्षण चलाया जा रहा है, लेकिन डिस्क पूर्ण है इसलिए IO का उपयोग करके यूनिट परीक्षण उम्मीदों को विफल कर देगा।
94239

हममम। नहीं, मैं गलत था। उन परीक्षणों को सही ढंग से निष्पादित नहीं किया गया था। बाद में इन सभी टिप्पणियों को हटा देंगे।
94239

3

अच्छा प्रश्न। सामान्य तौर पर मैं कुछ कारणों से कोड-कवरेज से कोड को बाहर करने की प्रवृत्ति रखता हूं, जैसे यह है:

  • उत्पन्न
  • विरासत (अब अपडेट नहीं)
  • यहाँ यह आता है: कुछ परतों, मैं परीक्षण करने का इरादा नहीं है

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

परंतु:

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

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


1

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

मेरी वर्तमान परियोजनाओं में, हम सभी कोड को मैट्रिक्स में भी शामिल करते हैं, एक अपवाद के साथ: उत्पन्न कोड, स्थिर विश्लेषण चेतावनी के ढेर का उत्पादन। जैसा कि इस कोड में आमतौर पर बिना किसी तर्क के विनम्र POD कक्षाएं होती हैं, वैसे भी वहाँ परीक्षण करने के लिए कुछ भी नहीं है।


1

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

अपने सीमित ज्ञान के साथ मुझे यह कहना है:

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

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


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

0

कुछ बहिष्करण समझ में आता है (बॉयलर प्लेट कोड जिसका कोई वास्तविक प्रभाव नहीं है या आपकी परियोजना के कामकाज पर प्रभाव की क्षमता सही ढंग से नहीं है)। यहां तक ​​कि एक मीट्रिक के रूप में अभी भी कोड कवरेज इकट्ठा करना व्यर्थ है क्योंकि यह आपको वैसे भी उपयोगी कुछ भी नहीं बताता है। 100% कोड कवरेज वास्तविक लक्ष्य नहीं है, और कम कवरेज संख्या भी परियोजना के आधार पर खराब नहीं हो सकती है, यह संभव हो सकता है कि 20-30% कोड कवरेज में वह सब कुछ शामिल हो जो परीक्षण के लायक है। कोड कवरेज आपको केवल आपके कोड का X% बताता है जो वास्तव में कवर करने लायक है, जो किसी प्रकार की अज्ञात गुणवत्ता का परीक्षण है।


0

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

आपकी बहिष्कृत परतों में 0% कवरेज होगा, और आपके परीक्षण किए गए क्षेत्रों में आपके द्वारा उल्लिखित 60% कवरेज होगा। आकार की जानकारी लोगों को यह समझने में मदद करेगी कि कितना अप्रयुक्त या परीक्षण किया गया है। यदि आप शायद बाहर की परतों के लिए परीक्षण बना रहे हैं, और यदि आपके मौजूदा परीक्षण काम कर रहे हैं, तो बग की जानकारी आपको सूचित करेगी।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.