माप कोड कवरेज केवल नए कोड

Question

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

कोई विचार?

ढेर:

जावा 1.5 JUnit Cobertura हडसन

Answer 1

पर एक नज़र emma.sourceforge और संबद्ध ग्रहण प्लगइन here (आप ग्रहण का उपयोग कर रहे हैं)

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

Answer 2

हमारे पास एक समान स्थिति थी .. नया कोड परीक्षण करना चाहता था लेकिन एक ही समय में सभी पुराने कोड का परीक्षण नहीं कर सका। हमने जो किया वह बिल्कुल ठीक नहीं है, लेकिन आपको एक विचार दे सकता है।

हमारे पास linecoverage.standard नामक एक फ़ाइल है, और एक फ़ाइल जिसे शाखाcover.standard कहा जाता है जो बिल्ड सर्वर (और स्थानीय प्रतियां) पर रहता है। उनके पास वर्तमान लाइन और शाखा कवरेज सीमाओं के साथ एक संख्या है। यदि चेक इन कोड मानक से नीचे है, तो यह बिल्ड विफल हो जाता है। यदि यह मानक पर है तो यह निर्माण को पास करता है। यदि यह मानक से ऊपर है, तो वर्तमान कवरेज के बराबर एक नया मानक लिखा जाता है।

इसका मतलब है कि हमारा कोड कवरेज कभी भी खराब नहीं होगा, और धीरे-धीरे बढ़ना चाहिए। यदि नया कोड 90% है, तो कवरेज रेंगना जारी रहेगा। आप एक लक्ष्य भी निर्धारित कर सकते हैं जैसे प्रत्येक सप्ताह 1 तक मानक बढ़ाएं जब तक कि यह आपके अंतिम लक्ष्य (9 0%) तक न हो जाए। एक सप्ताह से पुराने कोड में कुछ परीक्षण जोड़ने के लिए एक बुरा विचार नहीं है, अगर यह पर्याप्त समय पर फैल गया है।

हमारे वर्तमान कवरेज एक साल पहले के तहत एक 0% दर से आने वाले बहुत अच्छी 75% ish पर निर्भर है ...।

Answer 3

मैंने जीसीओवी के आउटपुट के साथ संयुक्त svn blame का उपयोग कर एक बड़ी सी ++ परियोजना के लिए ऐसा किया। यदि आप उन दोनों परिणामों को एक साथ जोड़ते हैं तो आपके पास प्रत्येक पंक्ति के लिए संशोधन जानकारी और कवरेज जानकारी होती है। मैं वास्तव में सभी एक डेटाबेस में यह लोड प्रश्नों करने के लिए (जैसे मुझे दिखाने के सब खुला r1234 के बाद से जो द्वारा लिखित लाइनों)। यदि आप केवल एक कुल संख्या चाहते हैं तो आप अपने कुल में 'पुरानी' अनदेखी लाइनों को गिनने से बच सकते हैं।

Answer 4

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

इसे पूरा करने के दो सबसे अच्छे तरीके हैं ए) कोडबेस को दो स्रोत पेड़ों (दो निर्भरताओं के बीच निर्भरता) में विभाजित करें, या बी) एक एकल परियोजना में दो अलग-अलग पैकेज पदानुक्रम बनाए रखें।

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

एक बार ऐसा कर मिल गया है, या तो Cobertura समायोजित इतना है कि यह केवल बिट्स आप चाहते हैं का विश्लेषण कर रहा है, या कम से कम अभी codebase की 'नई' भाग पर ध्यान केंद्रित। एक अतिरिक्त युक्ति यह है कि इस योजना में, "विरासत" से "नए" खंड में कोड के बिट्स को स्थानांतरित करना सबसे अच्छा होता है क्योंकि आप उन्हें प्रतिक्रिया देते हैं/उन्हें जोड़ते हैं (यदि कोड अक्सर दूसरी दिशा में आगे बढ़ रहा है, तो ऐसा नहीं है अच्छा :-)।

Answer 5

हमने इसे sonar.exclusions प्रॉपर्टी का उपयोग करके नीचे किया है: हम कोड कवरेज रिपोर्ट (कोबर्टुरा द्वारा रिपोर्ट) प्रदर्शित करने के लिए सोनार का उपयोग करते हैं।

ए) उन वर्गों की पहचान करें जिन्हें आप कवरेज रिपोर्ट नहीं चाहते हैं (विरासत कक्षाएं) अपने एससीएम सेमीडी लाइन क्लाइंट का उपयोग करें। जैसे: p4 फ़ाइलों // depot/... @ 2000/01/01, @ 2013/07/13 Git लॉग --until = "5 दिन पहले"

एक फ़ाइल में प्रत्यक्ष इस सूची। आपको उपयोग किए जाने वाले एससीएम उपकरण के आधार पर आपको कुछ पार्सिंग करने की आवश्यकता होगी और आपकी गंतव्य फ़ाइल में प्रति पंक्ति एक फ़ाइल नाम होना चाहिए।

eg. the destination file is excludeFile.list should look like below: 
abc.java 
xyz.java 
... 

बी) अब जब आप सोनार (जेनकींस जॉब से) के साथ एकीकृत करते हैं, तो नीचे दी गई संपत्ति का उपयोग करें।

-Dsonar.exclusions=<filename> 

और सोनार में अपने अंतिम कवरेज रिपोर्ट केवल आपके नए वर्गों में शामिल है (उपरोक्त उदाहरण में 13/07 के बाद जोड़ा)।