मेरे पास कोड कवरेज के बारे में कुछ पालतू सिद्धांत हैं जो मैं प्रश्न का उत्तर देने से पहले पहले समझाऊंगा।
पहले कुछ संदर्भ:
- Code coverage के कई प्रकार होते हैं, लेकिन मैं केवल लाइन कवरेज के बारे में बात करने जा रहा हूँ, लेकिन आप एक अलग तरह से प्रतिस्थापित करने का सक्षम होना चाहिए।
- प्रश्न से: "... कोई यूनिट परीक्षण और कोड कवरेज बूंदों के बिना नए कोड में जांचता है ..." जो कि इसी तरह से संबंधित है: "कुछ (रिफैक्टर/डुप्लिकेट को हटाता है/एल्गोरिदम को प्रतिस्थापित करता है और) परीक्षण को हटा देता है कोड और कवरेज बूंदों। "
- कवरेज को एक एकल सूट चलाने के परिणामस्वरूप मापा जाना चाहिए। यह है कि, एप्लिकेशन को चलाने और बाहर से उत्तेजित नहीं है।
- प्रतिशत के रूप में कवरेज बहुत भ्रामक है।
मुझे इसके बारे में एक विचार था और वास्तव में आप केवल यह जानना चाहते हैं कि कोड की कितनी लाइनें शामिल नहीं हैं।
इस उत्तर पर मेरी टिप्पणी देखें: Ensure minimal coverage on new Subversion commits
- कवरेज जितना संभव हो उतना उच्च होना चाहिए। प्रश्न "... बैकस्लाइडिंग की अनुमति के बिना सुधार ..."
- 100% coverage is possible।
मैंने लाइब्रेरी के बावजूद इसे किया है।
मैं एक theory है कि आप जहाँ तक कोड कवरेज का सवाल है सिर्फ दो भागों में अपने कोड को विभाजित करना चाहिए:
- एक प्रभाग जहां सभी कोड 100% कवर किया जाता है।
- एक विभाजन जहां कोई कोड शामिल नहीं है।
या तो विभाजन कई परियोजनाओं द्वारा गठित किया जा सकता है, लेकिन विभाजन के सदस्यों को फाइलें होनी चाहिए (यह देखते हुए कि जावा और सी # दोनों में स्रोत फाइलें हैं) और अधिमानतः फाइलों के पूरे फ़ोल्डर। आपके पास पहले डिवीजन में प्रोजेक्ट का एक सेट और दूसरे डिवीजन में एक और सेट हो सकता है।
अब कवरेज की कमी की रिपोर्ट दूसरे विभाजन में लाइनों की संख्या है।
ऑपरेशन का तरीका यह होना चाहिए कि आप अपने कोड का परीक्षण कर रहे हैं और कोड बस 100% कवरेज डिवीजन में पड़ता है।हालांकि, अगर आपको कोड का एक मुश्किल टुकड़ा मिलता है जो आपके मस्तिष्क को परीक्षण करने का कोई तरीका नहीं ढूंढ पाता है, तो आपको रिफैक्टर करना चाहिए ताकि परीक्षण की बिट्स दूसरे विभाजन में स्थानांतरित न हो जाएं। वैकल्पिक रूप से आप एक मस्तिष्कवाही प्राप्त कर सकते हैं और एक परीक्षण खोजने में सक्षम हो सकते हैं जो दूसरे विभाजन को 0% से ऊपर उठाता है, जिस बिंदु पर आप पहले विभाजन में कोड को दोबारा प्रतिक्रिया देते हैं। इसका मतलब है कि प्रत्येक चेक-इन मेरे सैद्धांतिक आविष्कार को बनाए रखता है।
अब
, वापस सवाल का:
नहीं, मैं TeamCity बिल्कुल अलग JetBrains वेबसाइट पर एक संक्षिप्त देखो से पता नहीं है, इसलिए मैं कैसे कवरेज अद्यतन करने के लिए पता नहीं है, लेकिन मेरे सिद्धांत के अनुसार यह 100% या कुछ भी नहीं होना चाहिए, तो क्या आप प्रति परियोजना सीमा निर्धारित कर सकते हैं? यदि आप कर सकते हैं, तो पहले विभाजन के लिए 100% की निश्चित सीमा।
यदि आप दो डिवीजन प्राप्त कर सकते हैं तो आप दूसरे विभाजन के लिए कोड मीट्रिक की एक पंक्ति के साथ स्वचालित अपडेट चीज करना चाहते हैं, प्रगतिशील रूप से कम बेहतर है।
+1। क्या एक शानदार जवाब है! – bragboy
+1 अच्छा जवाब - मेरे पास समान सिद्धांत हैं और मैंने हमारे कोड बेस में कई पुस्तकालयों के लिए 100% कवरेज प्राप्त किया है। –