क्या 100% कोड कवरेज एक पाइप सपना है?

Question

यह भारी jquery / backbonejs वेब अनुप्रयोगों में 100% कोड कवरेज की उम्मीद करना संभव है? क्या 100% कवरेज के कारण स्प्रिंट को विफल करना उचित है जब वास्तविक कोड कवरेज जावास्क्रिप्ट / jquery में लगभग 92% -95% हो जाता है?

Comments

"फेल ए स्प्रिंट" सुनने में अजीब लगता है ...

— डोनल फेलो

यह एक asymptote है।

— रॉबर्ट हार्वे

यहां तक ​​कि अगर आपके पास पूर्ण कवरेज है, तो कुछ कीड़े नहीं मिलेंगे, इसलिए सब कुछ ठीक करने के लिए उस संख्या पर भरोसा न करें

— शाफ़्ट सनकी

कुछ भी संभव है। असली सवाल यह है कि क्या 100% कोड कवरेज का मूल्य समय और संसाधनों में लागत के लायक है।

— जॉनफेक्स

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

— मेसन व्हीलर

Answer 1

यह उतना ही यथार्थवादी है जितना कि यह अवास्तविक है।

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

अवास्तविक
आप 0% कवरेज पर शुरू कर रहे हैं ...
परियोजना कई के साथ राक्षसी है, कई त्रुटि पथ जो फिर से बनाना या ट्रिगर करना मुश्किल है।
प्रबंधन यह सुनिश्चित करने के लिए प्रतिबद्ध / निवेश करने को तैयार नहीं है कि कवरेज है।

मैंने बिना किसी कवरेज से लेकर सभ्य तक की परियोजनाओं के सरगम ​​का काम किया है। कभी भी 100% के साथ एक परियोजना नहीं है, लेकिन निश्चित रूप से कई बार मैं कामना करता था कि हम 100% कवरेज के करीब हों।
अंततः सवाल यह है कि क्या मौजूदा कवरेज टीम को उत्पाद की शिपिंग में सहज होने के लिए आवश्यक मामलों में से पर्याप्त है।

हम आपकी परियोजना पर विफलता के प्रभाव को नहीं जानते हैं, इसलिए हम यह नहीं कह सकते हैं कि 92% या 95% पर्याप्त है, या यदि 100% वास्तव में आवश्यक है। या उस मामले के लिए, 100% पूरी तरह से आपके द्वारा अपेक्षित हर चीज का परीक्षण करता है।

Comments

... और सिर्फ इसलिए कि आपके पास 100% कोड कवरेज का मतलब यह नहीं है कि आपके पास 100% शाखा कवरेज है, इसलिए 100% कोड कवरेज के साथ भी आप बहुत कुछ याद कर सकते हैं।

— ब्रायन ओकले

परियोजना के आकार के लिए +1। छोटे, पुन: प्रयोज्य और परीक्षण योग्य घटकों में टूटने से हमें स्वयं ~ 95% कवरेज प्राप्त करने की अनुमति मिली है। 100% कवरेज आवश्यक नहीं है। एकीकरण परीक्षण को इकाई परीक्षण अंतराल को कवर करना चाहिए।

— अपूर्व खुरसिया

@BryanOakley ... और आपके परीक्षण भी व्यर्थ हो सकते हैं, या कुछ भी परीक्षण नहीं किया जा सकता है

— David_001

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

— इज़्काटा

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

— एंड्रिया

Answer 2

परीक्षण कौन करता है?

यह बहुत है अनुभवहीन सबसे अच्छे रूप में और अवास्तविक भी सैद्धांतिक अर्थ में और अव्यावहारिक एक व्यावसायिक समझ में।

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

कोड की हर पंक्ति का परीक्षण करना एक अच्छा लक्ष्य नहीं है

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

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

रुकने की समस्या:

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

एलन ट्यूरिंग ने 1936 में साबित किया कि सभी संभावित प्रोग्राम-इनपुट जोड़े के लिए हॉल्टिंग समस्या को हल करने के लिए एक सामान्य एल्गोरिदम मौजूद नहीं हो सकता है। प्रमाण का एक महत्वपूर्ण हिस्सा एक कंप्यूटर और कार्यक्रम की गणितीय परिभाषा थी, जिसे ट्यूरिंग मशीन के रूप में जाना जाता था; ट्यूरिंग मशीनों के ऊपर हॉल्टिंग की समस्या न के बराबर है। यह निर्णय समस्या के पहले उदाहरणों में से एक है।

चूँकि आप यह भी साबित नहीं कर सकते हैं कि कुछ काम 100% काम करता है, इसलिए इसे अपना लक्ष्य बनाएं?

सादे और सरल, ज्यादातर मामलों में यह किसी भी व्यवसाय की समझ में नहीं आता है।

Comments

यह वास्तव में स्वीकृत उत्तर होना चाहिए। 100% कोड कवरेज लगभग 0% जितना खराब है।

— रायथल

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

— still_dreaming_1

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

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

— प्रेड्रग स्टोज्डिनोविक

Answer 3

ज्यादातर मामलों में, 100% कोड कवरेज का मतलब है कि आपने "धोखा" दिया है:

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

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

Comments

डीएसएल को धोखा देने के लिए चीजें कैसे बढ़ रही हैं?

— back2dos

@ back2dos - जब आप इकाई परीक्षण कह सकते हैं, तो आपके एम्बेडेड अजगर लिपियाँ, आप संभवतः अपने html टेम्प्लेट, या अपने CSS का परीक्षण नहीं कर रहे हैं, या उनमें कवरेज अनुमानों की दिशा में लाइनों की गिनती कर रहे हैं।

— दान मोनेगो

Answer 4

100% शाखा कवरेज के एक प्रभावशाली, वास्तविक दुनिया उदाहरण के लिए , देखें कि SQLite का परीक्षण कैसे किया जाता है ।

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

Answer 5

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

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

बहुत अधिक महत्वपूर्ण, परीक्षण सही हैं? क्या वे आपके व्यवसाय और आवश्यकताओं को सही ढंग से दर्शाते हैं? कोड कवरेज होने के लिए बस कोड कवरेज का कोई मतलब नहीं है अगर आप जो भी कर रहे हैं वह गलत तरीके से परीक्षण कर रहा है, या गलत कोड का परीक्षण कर रहा है। कहा जा रहा है, यदि आपके परीक्षण अच्छे हैं, तो 92-95% कवरेज बकाया है।

Comments

परीक्षण क्या होता है जब आपको त्रुटि मामलों के अजीब संयोजन मिलते हैं और विफलता-से-प्रतिक्रियाएं असाधारण रूप से मुश्किल हो सकती हैं।

— डोनल फैलो

समझ नहीं आ रहा है कि यूनिट टेस्टिंग की अपील के इन कठिन समस्याओं के साथ प्रस्तुत करने पर आपका सिस्टम क्या करेगा? इसके अलावा, यूनिट परीक्षणों और एकीकरण परीक्षणों के बीच यहां थोड़ा भ्रम है।

— पीटर स्मिथ

इस के unit testingसाथ integration testing, परीक्षण कोड जो आपने नहीं लिखा था integrationपरीक्षण कर रहा है। टीसीपी स्टैक ओएस में है जिसे आपको परीक्षण नहीं करना चाहिए, आपको यह मानना ​​चाहिए कि यह पहले से ही परीक्षण किया गया है कि किसने इसे लिखा है।

Answer 6

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

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

Comments

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

— still_dreaming_1

Answer 7

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

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

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

क्या 100% कवरेज के कारण स्प्रिंट को विफल करना उचित है जब वास्तविक कोड कवरेज जावास्क्रिप्ट / jquery में लगभग 92% -95% हो जाता है?

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

Comments

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

— still_dreaming_1

@ still_dreaming_1, आपको लगता है कि आपने मेरे कथन का समर्थन किया है और खुद का विरोध किया है। फीचर्स को वापस लाना या अपनी समय सीमा में फेरबदल करना समझौता है, जिनमें से प्रत्येक परियोजना की लागत और हितधारक अपेक्षाओं को प्रभावित कर सकता है। परीक्षण विरासत कोड जिसे पहले पूरी तरह से परीक्षण नहीं किया गया है, अत्यंत कठिन है, क्योंकि आपको न केवल कोड को समझना होगा, बल्कि यह मूल निर्माता के इरादे, और लेखन परीक्षण जो मौजूदा विरासत कोड व्यवहार को कैप्चर करते हैं, जरूरी नहीं दिखाते हैं माना जाता है कि कोड पूरी तरह से काम करता है।

— रॉबिन्स

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

— still_dreaming_1

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

— still_dreaming_1

Answer 8

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

क्या आपके सामने कुछ विशेष बाधा आ रही है जो आपको उन आखिरी कुछ लाइनों को रोकने से रोक रही है? यदि नहीं, तो 95% से 100% कवरेज प्राप्त करना सीधा है, इसलिए आप इसे कर सकते हैं। आप यहाँ पूछ रहे हैं के बाद से, मुझे लगता है करने के लिए है कि वहाँ जा रहा हूँ है कुछ। वह कुछ है क्या?

Comments

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

— still_dreaming_1

Answer 9

92% ठीक है। मुझे लगता है कि असली सवाल हैं:

• क्या 92% 'नया' मानदंड है? यदि अगले स्प्रिंट में 88% परीक्षण है, तो क्या यह ठीक होगा? यह अक्सर परीक्षण सूटों को छोड़ने की शुरुआत है।

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

• क्या लापता परीक्षणों में वापस जाने और भरने की योजना है?

• आप परीक्षण क्यों कर रहे हैं? ऐसा लगता है कि फोकस लाइन का% कवर है कार्यक्षमता नहीं है

Comments

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

— still_dreaming_1

Answer 10

मार्टिन फाउलर अपने ब्लॉग में लिखते हैं :I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

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

कुछ सबक हैं:

• 100% कवरेज असामान्य है लेकिन प्राप्त करने योग्य है
• 100% कवरेज कभी-कभी आवश्यक होता है
• 100% कवरेज नए जोखिम में लाता है
• 100% -मेट्रिक के लिए अनुकूलन न करें
• कवरेज को अधिकतम करने के लिए एक उचित रणनीति विकसित करें
• अच्छी गुणवत्ता के लिए 100% कवरेज पर्याप्त स्थिति नहीं है

Answer 11

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

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

आज के औजारों के साथ सही ढंग से प्रोग्रामिंग का कार्य असंभव है। कोड लिखना बहुत मुश्किल है जो पूरी तरह से सही है, और इसमें कीड़े नहीं हैं। यह स्वाभाविक नहीं है। इसलिए, कोई अन्य स्पष्ट विकल्प नहीं है, हम TDD, और ट्रैकिंग कोड कवरेज जैसी तकनीकों की ओर मुड़ते हैं। लेकिन जब तक अंतिम परिणाम अभी भी एक अप्राकृतिक प्रक्रिया है, तब तक आपको लोगों को इसे लगातार और खुशी से करने के लिए कठिन समय मिलेगा।

100% कोड कवरेज हासिल करना एक अप्राकृतिक कृत्य है। ज्यादातर लोगों के लिए, उन्हें यह हासिल करने के लिए मजबूर करना यातना का एक रूप होगा।

हमें उन प्रक्रियाओं, औजारों, भाषाओं और कोड की जरूरत है जो हमारे प्राकृतिक मानसिक मॉडल के मानचित्र को दर्शाते हैं। यदि हम ऐसा करने में विफल रहते हैं, तो किसी उत्पाद में गुणवत्ता का परीक्षण करने का कोई तरीका नहीं है।

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

यहां कोडिंग को अधिक प्राकृतिक बनाने के लिए कुछ प्रयास किए गए हैं:

https://github.com/jcoplien/trygve

https://github.com/still-dreaming-1/PurposefulPhp

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

Answer 12

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

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

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

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

Answer 13

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

Comments

ओह! तो कोई इस बात से परेशान है कि मैंने इस समस्या का जवाब नहीं दिया; परीक्षण एक बेकार है ... मुझे परवाह नहीं है अगर यह लोकप्रिय है। यह कभी काम नहीं करेगा। यह नहीं कर सकते। होशियार कंप्यूटर वैज्ञानिकों ने इसे जाना है (दिक्जस्त्र, नुथ, होरे एट अल।)। मुझे लगता है कि यदि आप एक जावास्क्रिप्ट प्रोग्रामर हैं जो एक्सएक्सट्रीम प्रोग्रामिंग का शौक है, तो आप उन क्रैंक के बारे में परवाह नहीं करते हैं, हालांकि। ब्लाह, जो भी हो, जो परवाह करता है ... भद्दा कोड लिखता है। अपशिष्ट CO ^ 2 अपने परीक्षण चला रहा है। - मेरा मतलब है, किसके पास बैठने और सोचने का समय है? हमने कंप्यूटर को निर्यात किया है।

— फूफा

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

— लूनीवोर