मैं सी ++ कोड की अचूक लाइनों को अनदेखा करने के लिए gcov कैसे कहूं?

Question

मैं अपने सी ++ कोड में कवरेज मापने के लिए जीसीओवी का उपयोग कर रहा हूं। मैं 100% कवरेज प्राप्त करना चाहता हूं, लेकिन इस तथ्य से बाधित हूं कि कोड की कुछ पंक्तियां सैद्धांतिक रूप से अप्रचलित हैं (विधियों को लागू करने की आवश्यकता है, जिन्हें कभी नहीं कहा जाता है, switch कथन की डिफ़ॉल्ट शाखाएं, आदि।)। इनमें से प्रत्येक शाखा में assert(false); कथन शामिल है, लेकिन gcov अभी भी उन्हें अन-हिट के रूप में चिह्नित करता है।

मैं इन शाखाओं को अनदेखा करने के लिए gcov बताने में सक्षम होना चाहता हूं। क्या जीसीओवी को जानकारी देने का कोई तरीका है - स्रोत कोड को एनोटेट करके, या किसी अन्य तंत्र द्वारा?

Answer 1

कृपया lcov का उपयोग करें।यह gcov की जटिलता को छुपाता है, अच्छा उत्पादन पैदा करता है, परीक्षण प्रति विस्तृत उत्पादन की अनुमति देता है, आसान फ़ाइल को छानने और सुविधाओं - टा-TAA - पहले से ही की समीक्षा की लाइनों के लिए लाइन मार्कर:

geninfo से (1):

निम्नलिखित मार्कर geninfo द्वारा मान्यता प्राप्त हैं:

• LCOV_EXCL_LINE
  • इस मार्कर युक्त लाइन्स बाहर रखा जाएगा।
• LCOV_EXCL_START
  • एक बहिष्कृत खंड की शुरुआत के निशान। वर्तमान रेखा इस खंड का हिस्सा है।
• LCOV_EXCL_STOP
  • एक बहिष्कृत अनुभाग के अंत में चिह्नित करता है। वर्तमान रेखा इस खंड का हिस्सा नहीं है।

Answer 2

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

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

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

Answer 3

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

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

मुझे यह थोड़ा अजीब लगता है कि यह कहने के लिए कि कोड पर कार्यशील आवश्यकताओं वाले स्पेक के बजाय कोड होना चाहिए। विशेष रूप से, इसका मतलब है कि आपके परीक्षण उन आवश्यकताओं का परीक्षण नहीं कर रहे हैं, जो कि किसी भी आवश्यकता को कार्यात्मक रखने के लिए एक अच्छा कारण है। निजी तौर पर मैं यह कहने के लिए spec को संशोधित करना चाहता हूं, "अगर अमान्य enum मान के साथ बुलाया जाता है, तो फ़ंक्शन assert विफल हो जाएगा। कॉलर्स रिलीज़ मोड में अमान्य एनम मान के साथ फ़ंक्शन को कॉल नहीं करेंगे"। या कुछ ऐसे।

संभवतः यह वर्तमान में क्या कहता है, "सभी स्विच स्टेटमेंट्स के पास एक डिफ़ॉल्ट मामला होना चाहिए" के आधार पर है। लेकिन इसका मतलब है कि कोडिंग मानकों को मृत कोड पेश करके अवलोकन योग्य व्यवहार (कम से कम, gcov के तहत देखने योग्य) में हस्तक्षेप कर रहे हैं। कोडिंग मानकों को ऐसा नहीं करना चाहिए, इसलिए यदि संभव हो तो कार्यात्मक स्पेक को कोडिंग मानकों का विवरण लेना चाहिए।

विफल होने पर, आप #if !GCOV_BUILD में अस्थिर कोड को लपेट सकते हैं, और जीसीओवी के लाभ के लिए एक अलग निर्माण कर सकते हैं। यह बिल्ड कुछ आवश्यकताओं को विफल कर देगा, लेकिन कोड के आपके विश्लेषण पर सशर्त सही है, यह आपको विश्वास दिलाता है कि परीक्षण सूट अन्य सभी का परीक्षण करता है।

संपादित करें: आप कहते हैं कि आप एक डोडी कोड जनरेटर का उपयोग कर रहे हैं, लेकिन आप स्रोत कोड को एनोटेट करके समाधान मांग रहे हैं। यदि आप स्रोत बदल रहे हैं, तो क्या आप कई मामलों में मृत कोड को हटा सकते हैं? ऐसा नहीं है कि उत्पन्न स्रोत बदलना आदर्श है, लेकिन जरूरतों को जरूरी है ...