यूनिट परीक्षणों (और क्यों) के लिए एक उचित कोड कवरेज% क्या है? [बन्द है]

Question

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

कृपया बताएं कि आप अपने उत्तर पर कैसे पहुंचे (क्योंकि अगर आपने किया था तो एक नंबर था, तो मैं वह सब खुद ही कर सकता था;)

Comments

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

— सभी

% प्रतीक मेट्रिक्स के लिए कोड गंध है (सामान्य रूप से भी% एक बकवास गंध है)

— हर्नान ईचे

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

— स्के

यह प्रश्न क्यों हटाया या ठीक से संपादित नहीं किया गया है इसने इतनी दिलचस्पी इकट्ठा की लेकिन यह पूरी तरह से भ्रामक है।

— स्के

Answer 1

अल्बर्टो साविया का यह गद्य सटीक रूप से उस प्रश्न का उत्तर देता है (उस पर एक अच्छी तरह से मनोरंजक तरीके से!)।

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

टेस्टिवस ऑन टेस्ट कवरेज

एक सुबह, एक प्रोग्रामर ने महान गुरु से पूछा:

“मैं कुछ यूनिट परीक्षण लिखने के लिए तैयार हूं। मुझे किस कोड कवरेज के लिए लक्ष्य बनाना चाहिए? "

महान गुरु ने जवाब दिया:

"कवरेज के बारे में चिंता न करें, बस कुछ अच्छे परीक्षण लिखें।"

प्रोग्रामर मुस्कुराया, झुका, और चला गया।

...

उस दिन बाद में, एक दूसरे प्रोग्रामर ने एक ही सवाल पूछा।

महान गुरु ने उबलते पानी के एक बर्तन पर इशारा किया और कहा:

"मुझे उस बर्तन में चावल के कितने दाने डालने चाहिए?"

प्रोग्रामर, हैरान, उत्तर दिया:

“मैं आपको कैसे बता सकता हूँ? यह इस बात पर निर्भर करता है कि आपको कितने लोगों को खाना खिलाना है, वे कितने भूखे हैं, आप कौन सा खाना परोस रहे हैं, आपके पास कितना चावल उपलब्ध है, इत्यादि। ”

"बिल्कुल," महान गुरु ने कहा।

दूसरा प्रोग्रामर मुस्कुराया, झुका, और चला गया।

...

दिन के अंत में, एक तीसरा प्रोग्रामर आया और कोड कवरेज के बारे में एक ही सवाल पूछा।

"अस्सी प्रतिशत और कम नहीं!" मस्त आवाज़ में मास्टर को दोहराया, मेज पर उसकी मुट्ठी तेज़ कर दी।

तीसरा प्रोग्रामर मुस्कुराया, झुका, और चला गया।

...

इस अंतिम उत्तर के बाद, एक युवा प्रशिक्षु ने महान गुरु से संपर्क किया:

“महान गुरु, आज मैं आपको तीन अलग-अलग उत्तरों के साथ कोड कवरेज के बारे में एक ही सवाल का जवाब देता हूं। क्यों?"

महान गुरु अपनी कुर्सी से खड़े हुए:

"आओ मेरे साथ कुछ ताजा चाय ले आओ और इसके बारे में बात करते हैं।"

जब वे गर्म हरी चाय पीने के साथ अपने कप भरते हैं, तो महान गुरु जवाब देने लगे:

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

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

"मैं देख रहा हूँ," युवा प्रशिक्षु ने कहा, "लेकिन अगर एक भी सरल उत्तर नहीं है, तो आपने तीसरे प्रोग्रामर 'अस्सी प्रतिशत और कोई कम' का जवाब क्यों दिया?"

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

"तीसरा प्रोग्रामर केवल सरल उत्तर चाहता है - भले ही कोई सरल उत्तर न हो ... और फिर वैसे भी उनका पालन नहीं करता है।"

युवा प्रशिक्षु और घोर महान गुरु ने चिंतन-मनन में अपनी चाय पी।

Comments

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

— पवित्रता

पवित्रता - आपके कथन को "दूसरे डेवलपर" की प्रतिक्रिया से स्पष्ट रूप से दिखाया गया है। व्यक्तिगत अनुभव इसे तय करना चाहिए।

— जॉन लीमजप

एकदम सही जवाब। मेट्रिक्स अच्छा कोड नहीं बनाते हैं। आप 100% कवरेज के साथ भद्दा कोड लिख सकते हैं और यह कोड को अच्छा काम नहीं करता है। मेरे से +1, शर्म की बात है मैं और अधिक नहीं कर सकता :)

— रोब कूपर

4 साल बाद, और अभी भी उपयोगी है। बस आज सुबह मेरे दो सहयोगियों पर यह खींच लिया।

— सिकीहिपी

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

— samspot

Answer 2

कोड कवरेज एक भ्रामक मीट्रिक है यदि 100% कवरेज आपका लक्ष्य है (सभी सुविधाओं के 100% परीक्षण के बजाय)।

• एक बार सभी लाइनों को हिट करके आप 100% प्राप्त कर सकते हैं। हालाँकि आप अभी भी एक विशेष अनुक्रम (तार्किक पथ) का परीक्षण करने से चूक सकते हैं जिसमें वे रेखाएँ हिट होती हैं।
• आप 100% प्राप्त नहीं कर सकते हैं लेकिन फिर भी अपने सभी 80% / फ्रीक उपयोग किए गए कोड-रास्तों का परीक्षण कर चुके हैं। परीक्षण है कि हर 'फेंक ExceptionTypeX' या इसी तरह के रक्षात्मक प्रोग्रामिंग गार्ड आप एक 'अच्छा है' नहीं है 'होना चाहिए' का परीक्षण करने के बाद

इसलिए अपने या अपने डेवलपर्स पर पूरी तरह से भरोसा करें और उनके कोड के माध्यम से हर रास्ते को कवर करें। व्यावहारिक बनें और जादुई 100% कवरेज का पीछा न करें। यदि आप अपना कोड TDD करते हैं तो आपको बोनस के रूप में 90% + कवरेज मिलना चाहिए। आपके द्वारा छूटे हुए कोड के चक्रों को उजागर करने के लिए कोड-कवरेज का उपयोग करें (ऐसा नहीं होना चाहिए यदि आप TDD हालांकि .. क्योंकि आप कोड को केवल टेस्ट पास बनाने के लिए लिखते हैं। कोई कोड इसके साथी परीक्षण के बिना मौजूद नहीं हो सकता है।)

Comments

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

— tddmonkey

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

— एक्सेसर्स

मुझे यकीन नहीं है कि आपके दूसरे बिंदु का क्या मतलब है "लेकिन फिर भी आपके सभी कोड-रास्तों का परीक्षण किया है"। यदि आप वास्तव में पूर्ण-पथ कवरेज का मतलब रखते हैं, तो नहीं, आपके पास 100-% लाइन / शाखा / निर्णय कवरेज के बिना पूर्ण-पथ कवरेज नहीं हो सकता है। वास्तव में, पूर्ण-पथ कवरेज आमतौर पर किसी भी गैर-तुच्छ कार्यक्रम में अप्राप्य है क्योंकि पथ बनाने में शाखाओं की दहनशील प्रकृति के कारण। en.wikipedia.org/wiki/Code_coverage#Other_coverage_criteria

— Zach Burlingame

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

— दाऊद इब्न करीम

+1 के लिए "कोड-कवरेज का उपयोग करें जो आपके द्वारा छूटे हुए कोड को उजागर करने के लिए"। यह मूल रूप से वह मीट्रिक है जिसके लिए अच्छा है।

— beluchin

Answer 3

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

मुझे परवाह नहीं है अगर मेरे पास कोड होगा जो परीक्षणों में शामिल नहीं है, लेकिन मुझे परवाह है कि अगर मैं अपने कोड को रिफ्लेक्टर करूंगा और एक अलग व्यवहार होगा। इसलिए, 100% कार्यक्षमता कवरेज मेरा एकमात्र लक्ष्य है।

Comments

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

— दाऊद इब करीम

यदि आप कोड की सभी पंक्तियों को हिट किए बिना सभी कार्यक्षमता प्रदान कर सकते हैं, तो कोड के उन अतिरिक्त लाइनों को क्या कर रहे हैं?

— जेन टिम्मरमैन

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

— टॉफी

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

— स्केटरड्रम्स

Answer 4

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

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

कोड कवरेज आवश्यकताओं को कब सेट करें

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

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

कुछ विशिष्ट मामले जहां एक अनुभवजन्य मानक हो सकता है मूल्य जोड़ सकते हैं:

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

कौन से मेट्रिक्स का उपयोग करना है

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

जब आप मानकों को सेट करने के लिए उनका उपयोग कर सकते हैं, तो मैं दो सामान्य मैट्रिक्स का उपयोग करूँगा।

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

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

कितने प्रतिशत की आवश्यकता

अंत में, मूल प्रश्न पर वापस जाएं: यदि आप कोड कवरेज मानकों को निर्धारित करते हैं, तो उस संख्या को क्या होना चाहिए?

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

कुछ संख्याएँ जिन्हें कोई भी चुन सकता है:

• 100% । आप इसे चुन सकते हैं क्योंकि आप सुनिश्चित करना चाहते हैं कि सब कुछ परीक्षण किया गया है। यह आपको परीक्षण गुणवत्ता में कोई अंतर्दृष्टि नहीं देता है, लेकिन आपको बताता है कि कुछ गुणवत्ता के कुछ परीक्षण ने प्रत्येक कथन (या शाखा, आदि) को छुआ है, फिर से यह आत्मविश्वास की डिग्री पर वापस आता है: यदि आपका कवरेज 100% से कम है। , आप जानते हैं कि आपके कोड का कुछ सबसेट अप्राप्त है।
  • कुछ का तर्क हो सकता है कि यह मूर्खतापूर्ण है, और आपको केवल अपने कोड के उन हिस्सों का परीक्षण करना चाहिए जो वास्तव में महत्वपूर्ण हैं। मेरा तर्क है कि आपको केवल अपने कोड के हिस्सों को बनाए रखना चाहिए जो वास्तव में महत्वपूर्ण हैं। बिना कोड को हटाकर भी कोड कवरेज में सुधार किया जा सकता है।
• 99% (या 95%, उच्च नब्बे के दशक में अन्य संख्या।) उन मामलों में उपयुक्त है जहां आप 100% के समान आत्मविश्वास का स्तर व्यक्त करना चाहते हैं , लेकिन अपने आप को कुछ मार्जिन छोड़ दें, जो कभी-कभी कठिन-से-परीक्षण कोने के बारे में चिंता न करें कोड।
• 80% । मैंने इस संख्या को कुछ समय के लिए देखा है, और यह पूरी तरह से नहीं पता है कि यह कहां से उत्पन्न होती है। मुझे लगता है कि यह a०-२० नियम का एक अजीब दुरुपयोग हो सकता है; आम तौर पर, यहाँ आशय यह दिखाना है कि आपके अधिकांश कोड का परीक्षण किया गया है। (हां, 51% भी "सबसे अधिक" होगा, लेकिन 80% अधिक चिंतनशील है कि अधिकांश लोगों को सबसे अधिक क्या मतलब है।) यह मध्य-भूमि के मामलों के लिए उपयुक्त है जहां "अच्छी तरह से जांचा गया" उच्च प्राथमिकता नहीं है (आप डॉन ' टी कम-मूल्य परीक्षणों पर प्रयास को बर्बाद करना चाहते हैं), लेकिन प्राथमिकता के लिए पर्याप्त है कि आप अभी भी कुछ मानक रखना चाहते हैं।

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

अन्य नोट

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

Comments

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

— घुंघराले

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

— 0x1mason

मुझे लगता है कि यह सबसे अच्छा उत्तर उपलब्ध है।

— बगकिलर

Answer 5

मेरा पसंदीदा कोड कवरेज एक तारांकन के साथ 100% है। तारांकन इसलिए आता है क्योंकि मैं ऐसे उपकरणों का उपयोग करना पसंद करता हूं जो मुझे कुछ पंक्तियों के रूप में चिह्नित करने की अनुमति देते हैं जो "गिनती नहीं" करते हैं। यदि मैंने 100% लाइनों को कवर किया है जो "गणना" करता है, तो मैं किया जाता हूं।

अंतर्निहित प्रक्रिया है:

1. मैं अपनी कार्यक्षमता और किनारे के उन मामलों को लिखने के लिए अपने परीक्षण लिखता हूं जिनके बारे में मैं सोच सकता हूं (आमतौर पर प्रलेखन से काम कर रहा हूं)।
2. मैं कोड कवरेज टूल चलाता हूं
3. मैं किसी भी लाइन या रास्तों की जांच नहीं करता हूं और कोई भी जिसे मैं महत्वपूर्ण या अप्राप्य नहीं मानता हूं (रक्षात्मक प्रोग्रामिंग के कारण) मैं गिनती के रूप में चिह्नित करता हूं
4. मैं उन लापता मामलों का उल्लेख नहीं करने पर लापता लाइनों को कवर करने और प्रलेखन में सुधार करने के लिए नए परीक्षण लिखता हूं।

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

Comments

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

— 20

क्या आप "उन उपकरणों को शामिल करने की अनुमति देते हैं जो [आप] कुछ पंक्तियों के रूप में कुछ पंक्तियों को चिह्नित करते हैं जो गिनती नहीं करते हैं"?

— डोमडम्ब्रोगिया

@domdambrogia PHP में एक उदाहरण के रूप में, अगर बर्गमैन के कोड कवरेज लाइब्रेरी का उपयोग करते हुए, के साथ एक लाइन एनोटेट करें // @codeCoverageIgnoreऔर इसे कवरेज से बाहर रखा जाएगा।

— बिशप

Answer 6

मेरे पास परीक्षण कवरेज पर एक और एनेकोड होगा जिसे मैं साझा करना चाहूंगा।

हमारे पास एक बड़ी परियोजना है, जिसमें ट्विटर पर, मैंने नोट किया कि, 700 यूनिट परीक्षणों के साथ, हमारे पास केवल 20% कोड कवरेज है ।

स्कॉट हैनेलमैन ने ज्ञान के शब्दों के साथ उत्तर दिया :

यह सही 20% है? क्या यह 20% है जो आपके उपयोगकर्ताओं को सबसे अधिक हिट करने वाले कोड का प्रतिनिधित्व करता है? आप 50 और परीक्षण जोड़ सकते हैं और केवल 2% जोड़ सकते हैं।

फिर, यह कोड कवरेज उत्तर पर मेरे टेस्टीवस पर वापस जाता है । बर्तन में कितना चावल डालना चाहिए? निर्भर करता है।

Comments

जाहिर है कि वहां सामान्य ज्ञान होना चाहिए। 50% कोड का परीक्षण कर रहे हैं, तो इसका बहुत उपयोग नहीं है।

— पवित्र

यह अधिक है ... आपके कवरेज में आपके आवेदन की मुख्य कार्यक्षमता पर खर्च किया गया है, या क्या यह बेकार सुविधाओं का परीक्षण कर रहा है / अच्छा-से-कल्पित है?

— जॉन लीमजप

आपके कोड का एक बड़ा% लगता है या तो बॉयलरप्लेट, या अपवाद हैंडलिंग, या सशर्त "डिबग मोड" सामान है

— एरिक एरोनिटी

Answer 7

एक अच्छी तरह से डिजाइन प्रणाली के लिए, जहां इकाई परीक्षणों ने शुरू से ही विकास को प्रेरित किया है, मैं कहूंगा कि 85% एक काफी कम संख्या है। परीक्षण योग्य होने के लिए डिज़ाइन की गई छोटी कक्षाओं को इससे बेहतर कवर करना मुश्किल नहीं होना चाहिए।

इस प्रश्न को कुछ इस तरह से खारिज करना आसान है:

• कवर की गई रेखाएं परीक्षण किए गए तर्क के बराबर नहीं हैं और किसी को प्रतिशत में बहुत अधिक नहीं पढ़ना चाहिए।

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

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

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

• कम पानी का निशान (LWM), परीक्षण के तहत प्रणाली में अब तक देखी गई सबसे कम संख्या में देखी गई रेखाएं हैं
• उच्च जल मार्क (HWM), परीक्षण के तहत प्रणाली के लिए देखा गया उच्चतम कोड कवरेज प्रतिशत है

यदि हम LWM से ऊपर नहीं जाते हैं और हम HWM से नीचे नहीं जाते हैं तो नया कोड जोड़ा जा सकता है। दूसरे शब्दों में, कोड कवरेज को कम करने की अनुमति नहीं है , और नए कोड को कवर किया जाना चाहिए। ध्यान दें कि मुझे कैसे कहना चाहिए और क्या नहीं (नीचे समझाया गया है)।

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

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

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

और फिर, अगर प्रतिक्रिया लूप बहुत लंबा है तो एकीकरण प्रक्रिया में इस तरह से सेटअप करना पूरी तरह से अव्यावहारिक हो सकता है।

मैं कोड कवरेज मीट्रिक के दो और सामान्य लाभों का भी उल्लेख करना चाहूंगा।

• कोड कवरेज विश्लेषण गतिशील कोड विश्लेषण का हिस्सा है (जैसा कि स्थैतिक एक, यानी लिंट के विपरीत)। डायनामिक कोड एनालिसिस के दौरान पाई जाने वाली समस्याएं (शुद्ध परिवार जैसे टूल द्वारा, http://www-03.ibm.com/software/products/en/rational-purify-family ) अनइंस्टॉल की गई मेमोरी रीड (UMR) जैसी चीजें हैं। स्मृति लीक, आदि इन समस्याओं को केवल तभी पाया जा सकता है जब कोड एक निष्पादित परीक्षण मामले द्वारा कवर किया गया हो । एक परीक्षण मामले में कवर करने के लिए सबसे कठिन कोड आमतौर पर सिस्टम में असामान्य मामले हैं, लेकिन यदि आप चाहते हैं कि प्रणाली सुंदर तरीके से विफल हो (यानी दुर्घटना के बजाय त्रुटि का पता लगाएं) तो आप असामान्य मामलों को कवर करने में कुछ प्रयास करना चाहते हैं। गतिशील कोड विश्लेषण में भी। बस थोड़ी सी बुरी किस्मत के साथ, एक यूएमआर सेगफॉल्ट या इससे भी बदतर हो सकता है।

• लोग नए कोड के लिए 100% रखने पर गर्व करते हैं, और लोग अन्य कार्यान्वयन समस्याओं के समान जुनून के साथ परीक्षण समस्याओं पर चर्चा करते हैं। इस फ़ंक्शन को अधिक परीक्षण योग्य तरीके से कैसे लिखा जा सकता है? आप इस असामान्य मामले को कैसे कवर करने की कोशिश करेंगे आदि।

और एक नकारात्मक, पूर्णता के लिए।

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

Answer 8

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

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

सौभाग्य!

Answer 9

कई दुकानें परीक्षणों का महत्व नहीं रखती हैं, इसलिए यदि आप शून्य से ऊपर हैं तो कम से कम कुछ मूल्य की प्रशंसा है - तो यकीनन गैर-शून्य खराब नहीं है क्योंकि कई अभी भी शून्य हैं।

.Net दुनिया में लोग अक्सर 80% को तर्क के रूप में उद्धृत करते हैं। लेकिन वे इसे समाधान स्तर पर कहते हैं। मैं परियोजना स्तर पर माप करना पसंद करता हूं: यूआई परियोजना के लिए 30% ठीक हो सकता है यदि आपने सेलेनियम, आदि या मैनुअल परीक्षण प्राप्त किए हैं, तो डेटा परत परियोजना के लिए 20% ठीक हो सकता है, लेकिन 95% + व्यवसाय के लिए काफी प्राप्त हो सकता है नियम परत, यदि पूरी तरह से आवश्यक नहीं है। तो, समग्र कवरेज, 60% कह सकते हैं, लेकिन महत्वपूर्ण व्यावसायिक तर्क बहुत अधिक हो सकता है।

मैंने यह भी सुना है: 100% की आकांक्षा और आप 80% हिट करेंगे; लेकिन 80% की आकांक्षा और आप 40% मारा जाएगा।

नीचे पंक्ति: 80:20 नियम लागू करें, और अपने ऐप के बग की गिनती आपको गाइड करें।

Answer 10

कोड कवरेज सिर्फ एक और मीट्रिक है। अपने आप में, यह बहुत भ्रामक हो सकता है ( www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated देखें )। इसलिए आपका लक्ष्य 100% कोड कवरेज प्राप्त करना नहीं होना चाहिए, बल्कि यह सुनिश्चित करना है कि आप अपने आवेदन के सभी प्रासंगिक परिदृश्यों का परीक्षण करें।

Answer 11

85% चेकिन मानदंड के लिए एक अच्छी शुरुआत होगी।

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

Comments

आप उस प्रतिशत पर कैसे पहुंचे?

— पवित्र

एक फुटनोट के रूप में - यह उन परियोजनाओं के लिए गन्दा हो सकता है जहां स्वचालन मुश्किल है - जैसा कि हमेशा प्राप्त करने योग्य बनाम वांछनीय के बारे में व्यावहारिक होना चाहिए।

— सौतेला भाई

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

— सौतेला भाई

मैं आमतौर पर 1) प्रमुख रनटाइम कोड रास्तों से शुरू करता हूं 2) स्पष्ट अपवाद वाले मामले जो मैं स्पष्ट रूप से 3 फेंकते हैं) सशर्त मामले जो "विफलता" के साथ समाप्त होते हैं यह आपको आमतौर पर 70-80 रेंज में मिल जाता है फिर कोने के मामलों के लिए निराला, बग्स और प्रतिगमन, पैरामीटर फ़ज़िंग आदि तरीकों के इंजेक्शन को सक्षम करने के लिए रिफैक्टरिंग आदि मैं आमतौर पर मुख्य कोड के रूप में देव-संबंधित परीक्षणों को लिखने / रिफैक्ट करने के लिए कम से कम समय की अनुमति देता हूं।

— Stephbu

Answer 12

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

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

Answer 13

जब मुझे लगता है कि मेरा कोड पर्याप्त परीक्षण नहीं किया गया है, और मुझे यकीन नहीं है कि आगे क्या परीक्षण करना है, तो मैं कवरेज का उपयोग करके मुझे यह तय करने में मदद करता हूं कि आगे क्या परीक्षण करना है।

अगर मैं एक यूनिट टेस्ट में कवरेज बढ़ाता हूं - मुझे पता है कि यह यूनिट टेस्ट कुछ लायक है।

यह उस कोड के लिए जाता है जिसे कवर नहीं किया गया है, 50% कवर या 97% कवर किया गया है।

Comments

मैं पूरी तरह असहमत हूं। एक इकाई परीक्षण केवल कुछ के लायक है अगर वहाँ एक मौका है कि यह एक बग को उजागर करेगा, (या तो एक बग जो अभी मौजूद है या भविष्य में एक प्रतिगमन बग); या यदि यह आपकी कक्षा के व्यवहार का दस्तावेजीकरण करने में मदद करता है। यदि कोई विधि इतनी सरल है कि यह वास्तव में विफल नहीं हो सकती है, जैसे कि एक-पंक्ति पाने वाला, तो इसके लिए एक इकाई परीक्षण प्रदान करने में शून्य मान है।

— दाऊद इब्न करीम

मेरे पास एक लाइन पाने वालों में कीड़े थे। मेरे अनुभव से, कोई बग मुक्त कोड नहीं है। ऐसा कोई तरीका नहीं है जो वास्तव में विफल न हो।

— ईंटक

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

— लोवेल मोंटगोमरी

@LowellMontgomery और क्या होगा अगर आपके अन्य कोड के लिए परीक्षण उस एक-लाइन गटर की वजह से विफल हो जाता है (जो कि परीक्षण नहीं किया गया था)? यदि वन-लाइनर के लिए एक जगह परीक्षण किया गया था, तो असफल होने का कारण प्राप्त करना बहुत आसान होगा। यह वास्तव में खराब हो जाता है जब आपके पास कई अलग-अलग स्थानों में इस्तेमाल किए जा रहे सैकड़ों-लाइनर्स का परीक्षण नहीं किया जाता है।

— डैनियल

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

— लोवेल मोंटगोमरी

Answer 14

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

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

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

Answer 15

यदि आप समय की एक सभ्य राशि के लिए इकाई परीक्षण कर रहे हैं, तो मुझे इसका कोई कारण नहीं दिखता है कि यह 95% + के करीब नहीं है। हालाँकि, न्यूनतम पर, मैंने हमेशा 80% के साथ काम किया है, तब भी जब परीक्षण के लिए नया है।

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

Answer 16

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

दुर्भाग्य से, इनमें से अधिकांश परिणाम कंपनियों के लिए आंतरिक हैं, इसलिए कोई सार्वजनिक साहित्य नहीं हैं जो मैं आपको इंगित कर सकता हूं।

Answer 17

कोड कवरेज महान है, लेकिन केवल तब तक जब तक कि इससे प्राप्त होने वाले लाभ इसे प्राप्त करने की लागत / प्रयास को पछाड़ न दें।

हम पिछले कुछ समय से 80% के मानक पर काम कर रहे हैं, हालाँकि हमने इसे छोड़ने के लिए केवल निर्णय लिया है और इसके बजाय हमारे परीक्षण पर अधिक ध्यान केंद्रित किया है। जटिल व्यावसायिक तर्क आदि पर ध्यान देना,

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

Answer 18

संक्षिप्त उत्तर: 60-80%

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

Answer 19

की जाँच करें Crap4j । यह सीधे कोड कवरेज की तुलना में थोड़ा अधिक परिष्कृत दृष्टिकोण है। यह जटिलता के माप के साथ कोड कवरेज माप को जोड़ती है, और फिर आपको दिखाता है कि वर्तमान में कौन से जटिल कोड का परीक्षण नहीं किया गया है।

Answer 20

इस पहेली का मेरा उत्तर है कि आप जिस कोड का परीक्षण कर सकते हैं उसका 100% लाइन कवरेज है और जिस कोड का आप परीक्षण नहीं कर सकते, उसका 0% लाइन कवरेज है।

पायथन में मेरा वर्तमान अभ्यास मेरे .py मॉड्यूल को दो फ़ोल्डरों में विभाजित करने के लिए है: app1 / और app2 / और जब इकाई परीक्षण चल रहे हैं, तो उन दो फ़ोल्डरों के कवरेज की गणना करें और नेत्रहीन जांच करें (मुझे चाहिए किसी दिन स्वचालित चाहिए) कि app1 100% कवरेज और app2 में 0% कवरेज है।

जब / यदि मुझे पता चलता है कि ये संख्या मानक I जांच से भिन्न है और कोड के डिज़ाइन को बदल देती है ताकि कवरेज मानक के अनुरूप हो।

इसका मतलब यह है कि मैं लाइब्रेरी कोड के 100% लाइन कवरेज को प्राप्त करने की सिफारिश कर सकता हूं।

मैं कभी-कभी app2 की समीक्षा करता हूं / यह देखने के लिए कि क्या मैं वहां किसी भी कोड का परीक्षण कर सकता हूं, और अगर मैं इसे app1 में स्थानांतरित कर सकता / सकती हूं

अब मैं समग्र कवरेज के बारे में बहुत चिंतित नहीं हूं क्योंकि यह परियोजना के आकार के आधार पर बेतहाशा भिन्न हो सकता है, लेकिन आम तौर पर मैंने 70% को 90% से अधिक देखा है।

अजगर के साथ, मुझे एक धूम्रपान परीक्षण तैयार करने में सक्षम होना चाहिए जो कवरेज को मापने के दौरान स्वचालित रूप से अपना ऐप चला सकता है और बिना किसी आंकड़े के धूम्रपान परीक्षण का संयोजन करते समय 100% का एग्रेगेट हासिल कर सकता है।

Answer 21

दूसरे दृष्टिकोण से कवरेज देखना: नियंत्रण के एक स्पष्ट प्रवाह के साथ अच्छी तरह से लिखित कोड को कवर करना सबसे आसान है, पढ़ने में सबसे आसान है, और आमतौर पर कम से कम छोटी गाड़ी कोड है। मन में स्पष्टता और कमनीयता के साथ कोड लिखकर, और कोड के साथ इकाई परीक्षणों को समानांतर में लिखकर, आपको सर्वोत्तम परिणाम IMHO मिलता है।

Answer 22

मेरी राय में, जवाब "यह इस बात पर निर्भर करता है कि आपके पास कितना समय है"। मैं 100% हासिल करने की कोशिश करता हूं लेकिन अगर मेरे पास समय नहीं है तो मैं उपद्रव नहीं करता हूं।

जब मैं यूनिट परीक्षण लिखता हूं, तो उत्पादन कोड विकसित करते समय मैं जो टोपी पहनता हूं उसकी तुलना में मैं एक अलग टोपी पहनता हूं। मुझे लगता है कि परीक्षण किए गए कोड क्या करने का दावा करते हैं और ऐसी कौन सी परिस्थितियां हैं जो इसे तोड़ सकती हैं।

मैं आमतौर पर निम्नलिखित मानदंडों या नियमों का पालन करता हूं:

1. कि यूनिट टेस्ट मेरे कोड के अपेक्षित व्यवहार पर प्रलेखन का एक रूप होना चाहिए, अर्थात। अपेक्षित आउटपुट ने एक निश्चित इनपुट दिया और अपवाद यह हो सकता है कि ग्राहक पकड़ना चाहें (मेरे कोड के उपयोगकर्ताओं को क्या पता होना चाहिए?)

2. यूनिट टेस्ट से मुझे यह पता लगाने में मदद मिलेगी कि क्या स्थितियाँ हैं जिनके बारे में मैंने अभी तक नहीं सोचा है। (कैसे मेरे कोड को स्थिर और मजबूत बनाने के लिए?)

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

Answer 23

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

Comments

यदि आप TDD एनवायरमेंट में हैं, तो आपको संभवतः यूआई के लिए मॉडल व्यू प्रस्तुतकर्ता का उपयोग करना चाहिए।

— चार्ल्स ग्राहम

Answer 24

मुझे नहीं लगता कि ऐसा कोई B / W नियम हो सकता है।
महत्वपूर्ण विवरणों पर विशेष ध्यान देते हुए कोड की समीक्षा की जानी चाहिए।
हालाँकि, अगर इसका परीक्षण नहीं किया गया है, तो इसमें एक बग है!

Comments

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

— पवित्र

Answer 25

कोड की आलोचनात्मकता के आधार पर, कहीं भी 75% -85% अंगूठे का एक अच्छा नियम है। शिपिंग कोड निश्चित रूप से घर की उपयोगिताओं, आदि की तुलना में अधिक अच्छी तरह से परीक्षण किया जाना चाहिए।

Answer 26

यह आपके अनुप्रयोग विकास जीवनचक्र के किस चरण में है, इस पर निर्भर होना पड़ता है।

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

आपके डोमेन के आधार पर यह 95% के लिए शूट करने के लिए अनुचित नहीं है, लेकिन मुझे आपके औसतन 85% से 90% के औसत मामले को देखना होगा।

Answer 27

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

Answer 28

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

Answer 29

हम कुछ दिनों पहले तक after०% लक्ष्य बना रहे थे, लेकिन जब हमने बहुत अधिक जेनरेट किए गए कोड का उपयोग किया, तो हम% उम्र की परवाह नहीं करते, बल्कि समीक्षक को आवश्यक कवरेज पर एक कॉल करते हैं।

Answer 30

Testivus पोस्टिंग से मुझे लगता है कि उत्तर संदर्भ दूसरा प्रोग्रामर होना चाहिए। व्यावहारिक दृष्टिकोण से यह कहने के लिए हमें प्रयास करने के लिए पैरामीटर / लक्ष्य चाहिए। मेरा विचार है कि हमारे पास वास्तुकला, कार्यक्षमता (उपयोगकर्ता कहानियां) कोड का विश्लेषण करके एक चुस्त प्रक्रिया में "परीक्षण" किया जा सकता है, और फिर एक संख्या के साथ आ सकते हैं। टेलीकॉम क्षेत्र में अपने अनुभव के आधार पर मैं कहूंगा कि 60% जांच के लिए एक अच्छा मूल्य है।