कितना कोड कवरेज "पर्याप्त" है?

Question

हम अपने काम पर यहाँ कोड कवरेज के लिए एक धक्का शुरू कर रहे हैं, और यह मुझे सोचने के लिए मिला है .... कितना कोड कवरेज पर्याप्त है?

कोड कवरेज पर कम रिटर्न के बिंदु पर आप कब पहुँचते हैं? अच्छा कवरेज और पर्याप्त नहीं के बीच मिठाई स्थान क्या है? क्या यह आपके द्वारा बनाई जा रही परियोजना के प्रकार (यानी WPF, WCF, मोबाइल, ASP.NET) से भिन्न होता है (ये C # कक्षाएं हैं जिन्हें हम लिख रहे हैं।)

Comments

इसका कोई अच्छा जवाब नहीं है; " कितना यूनिट टेस्ट कवरेज क्या आप की जरूरत? " ARTIMA डेवलपर मंचों पर कुछ उपयोगी सलाह है।

— RN01

Answer 1

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

Comments

क्या WPF स्वाभाविक रूप से परीक्षण करना कठिन है, या आपने अभी तक बेहतर कवरेज प्राप्त करने के लिए सबसे अच्छी रणनीति बनाने के प्रयास में खर्च नहीं किया है?

— JBRWilkinson

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

— नूह रिचर्ड्स 2

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

— पीट

मुझे संख्या (70%) पसंद है। जैसे-जैसे मेरी टीमें ऊंची होती जाती हैं, मैं मूल्य के बजाय कवरेज के लिए परीक्षण ढूंढना शुरू कर देता हूं। WPF टिप्पणी पर, हम अभी शुरुआती दिनों में हैं। मतलब, हम आसानी से परीक्षण करने योग्य होने के लिए WPF कोड का निर्माण / संरचना नहीं कर रहे हैं। नकली मॉडल मदद करते हैं। कोड डिजाइन करते समय, इसे परीक्षण योग्य बनाने के लिए डिज़ाइन करें। और, हां, इस बिंदु पर सीमित उदाहरण हैं इसलिए आपने इसके बारे में सोचा होगा। अलग-अलग डेवलपर्स जहां टीडीडी के रूप में नहीं थे, उनसे अलग पहली बार उद्योग के कम अनुभव के लिए उन्हें पेश किया गया था।

— जिम रश

अधिक विशिष्ट होना WPF इकाई परीक्षण के लिए एक कुतिया है , अगर आपको किसी कारण से अधिक कवरेज की आवश्यकता है तो WPF कक्षाओं के कवरेज का सबसे आसान तरीका कोडित यूआई परीक्षण / एकीकरण परीक्षणों के साथ है

— jk।

Answer 2

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

Comments

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

— JBRWilkinson

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

— मैथ्यू एम।

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

— नूह रिचर्ड्स

Answer 3

"पर्याप्त" वह है जब आप अपने कोड में इस विश्वास के साथ बदलाव कर सकते हैं कि आप कुछ भी नहीं तोड़ रहे हैं। कुछ परियोजनाओं पर, जो 10% हो सकती है, दूसरों पर, यह 95% हो सकती है।

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

Comments

"टेस्ट जब तक डर ऊब के लिए बदल जाता है"

— ब्रैड मेस

कोड हटाने के बारे में टिप्पणी के लिए Upvote। मैं उस समय के लिए कोड कवरेज मेट्रिक्स का उपयोग करता हूं (वीएस में, जहां यह उन लाइनों को हाइलाइट करता है जो कवर नहीं हैं)।

— नूह रिचर्ड्स

ग्रेट कोट @ बामेसे

— जायरेनेट

Answer 4

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

Answer 5

कवरेज एक नज़र रखने के लिए एक मीट्रिक है, लेकिन यह अंतिम लक्ष्य नहीं होना चाहिए। मैंने उच्च कवरेज कोड के बहुत सारे (और शाब्दिक रूप से लिखे गए) को देखा है - 100% कवरेज (टीडीडी, ज़ाहिर है), अभी तक:

• अभी भी कीड़े आते हैं
• डिजाइन अभी भी खराब हो सकता है
• आप वास्तव में अपने आप को कुछ मनमानी कवरेज लक्ष्य के लिए शूटिंग कर सकते हैं - अपनी लड़ाई चुनें: पी

वहाँ एक "टेस्टीवस का रास्ता" प्रविष्टि है जो मुझे लगता है कि यहां संदर्भ के लिए उपयुक्त है :)

Answer 6

अधिकांश कोड का केवल 20% समय 80% चलेगा । एक कोड कवरेज विश्लेषण बहुत उपयोगी नहीं है जब तक कि यह निर्धारित करने के लिए कॉल ग्राफ के साथ जोड़ा न जाए कि सबसे अधिक परीक्षण करने की आवश्यकता क्या है। यह बताता है कि आपके किनारे के मामले कहां होने की संभावना है। आप केवल उन किनारे के मामलों के लिए 100 परीक्षणों के साथ आ सकते हैं, जो वास्तविक कोड के 5% से कम का गठन करते हैं।

इसलिए, महत्वपूर्ण पथों को परिभाषित करने वाले 20% में से 100% और बाकी के कम से कम 50% (कॉल ग्राफ़ के अनुसार) को कवर करना सुनिश्चित करें। यह आपको (लगभग) 70% - 75% कुल कवरेज मिलना चाहिए, लेकिन यह भिन्न होता है।

चेक के बिना महत्वपूर्ण किनारे के मामलों को छोड़ते समय 70% से अधिक कवरेज प्राप्त करने की कोशिश में समय न जलाएं।

Comments

कोड कवरेज उपकरण क्या परिभाषा से कॉल ग्राफ़ उत्पन्न नहीं करते हैं?

— JBRWilkinson

Answer 7

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

कभी-कभी इसका कारण वांछनीय से कम होता है 'जैसे समय से बाहर भाग गया' लेकिन जल्दी रिलीज के लिए ठीक हो सकता है। बाद में कवरेज को बढ़ावा देने के लिए क्षेत्रों को फ्लैग करना बेहतर है।

मैं महत्वपूर्ण उड़ान सॉफ्टवेयर पर काम करता हूं जहां गैर-महत्वपूर्ण प्रणालियों के लिए 100% स्टेटमेंट कवरेज उपयुक्त माना जाता है। अधिक महत्वपूर्ण प्रणालियों के लिए हम शाखा / निर्णय कवरेज की जांच करते हैं और एक तकनीक कॉल का उपयोग करते हैं MC / DC जो कभी-कभी पर्याप्त रूप से कठोर नहीं होती है।

हमें यह भी सुनिश्चित करना होगा कि हमने ऑब्जेक्ट कोड को भी कवर किया है।

यह मूल्य / लागत के मुकाबले हमारे मामले में जोखिम के बीच एक संतुलन है। बग गुम होने के जोखिम के आधार पर एक सूचित विकल्प की आवश्यकता होती है।

Answer 8

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

मेरे पास ऐसी परियोजनाएं हैं जहां वह बिंदु 0% है क्योंकि कवरेज को डिजाइन और अन्य परियोजनाओं को नुकसान पहुंचाए बिना गणना करना असंभव है जहां वह 92% है।

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

Answer 9

स्पेस क्रिटिकल सॉफ्टवेयर के लिए 100% स्टेटमेंट कवरेज की आवश्यकता होती है।

पहले तो इसका कोई मतलब नहीं है। हर कोई जानता है कि एक पूर्ण परीक्षण कवरेज का मतलब यह नहीं है कि कोड पूरी तरह से परीक्षण किया गया है और यह वास्तव में आवेदन का परीक्षण किए बिना 100% कवरेज प्राप्त करना मुश्किल नहीं है।

फिर भी, 100% कवरेज एक कम सीमा है: हालाँकि 100% कवरेज बग-मुक्त सॉफ़्टवेयर का प्रमाण नहीं है, लेकिन यह निश्चित है कि कम कवरेज के साथ कोड पूरी तरह से परीक्षण नहीं किया गया है और यह अंतरिक्ष महत्वपूर्ण सॉफ़्टवेयर के लिए बस अस्वीकार्य है।

Answer 10

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

100%

एक सार्वजनिक API के लिए, java.util कलेक्शंस की तरह, जो किसी डेटाबेस में युग्मित नहीं है और HTML को वापस नहीं करता है, मुझे लगता है कि 100% कवरेज एक महान शुरुआत लक्ष्य है, भले ही आप समय या अन्य के कारण 90-95% के लिए व्यवस्थित हों बाधाओं। आपके द्वारा फ़ीचर पूरा करने के बाद टेस्ट कवरेज बढ़ाना अन्य प्रकार की कोड समीक्षा की तुलना में अधिक विस्तृत स्तर की जांच है। यदि आपका एपीआई बिल्कुल लोकप्रिय है, तो लोग इसका उपयोग करेंगे, इसे उप-वर्ग में बदल देंगे, इसे वशीकरण कर सकते हैं, आदि उन तरीकों से जो आप उम्मीद नहीं कर सकते हैं। आप उनका पहला अनुभव बग, या डिज़ाइन निरीक्षण प्राप्त करना नहीं चाहते हैं!

90%

व्यावसायिक अवसंरचना कोड के लिए, जो डेटा संरचनाओं में लेता है और डेटा संरचनाओं को लौटाता है, 100% अभी भी एक अच्छा प्रारंभिक लक्ष्य है, लेकिन अगर यह कोड बहुत अधिक दुरुपयोग को आमंत्रित करने के लिए पर्याप्त सार्वजनिक नहीं है, तो शायद 85% अभी भी स्वीकार्य है?

75%

कोड के लिए जो स्ट्रिंग्स लेता है और रिटर्न करता है, मुझे लगता है कि यूनिट परीक्षण बहुत अधिक भंगुर है, लेकिन फिर भी कई स्थितियों में उपयोगी हो सकता है।

50% या उससे कम

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

0% के पास

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

अंतत: हालांकि, केवल एक मानव न्याय कर सकता है कि मनुष्य के लिए क्या समझदार है। यूनिट परीक्षण वहाँ आपकी मदद नहीं कर सकता। कभी-कभी यह कई मनुष्यों को न्याय करने में सक्षम बनाता है।

पूर्ण 0%

यह एक दुखद श्रेणी है और मुझे ऐसा लगता है कि इसे लिखने के लिए किसी व्यक्ति की कमी है। लेकिन किसी भी पर्याप्त रूप से बड़ी परियोजना में खरगोश छेद हैं जो किसी भी व्यावसायिक लाभ प्रदान किए बिना व्यक्ति-सप्ताह का समय चूस सकते हैं।

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

Answer 11

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

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

Answer 12

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

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

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