मैं एक बहुत बड़ी वित्तीय मूल्य निर्धारण प्रणाली के लिए परीक्षण का प्रबंधन करता हूं। हाल ही में हमारे मुख्यालय ने जोर देकर कहा है कि हम सत्यापित करते हैं कि हमारी परियोजना के हर हिस्से में एक सार्थक परीक्षण है। कम से कम वे एक प्रणाली चाहते हैं जो गारंटी देता है कि जब हम कुछ बदलते हैं तो हम अन्य उप-प्रणालियों में अनजाने परिवर्तनों को खोज सकते हैं। अधिमानतः वे कुछ ऐसा चाहते हैं जो हमारे सिस्टम में प्रत्येक घटक की शुद्धता को मान्य करता है।मेरे यूनिट-परीक्षणों के सार्थक कोड-कवरेज विश्लेषण कैसे करें?
यह स्पष्ट रूप से काफी काम होने जा रहा है! इसमें सालों लग सकते हैं, लेकिन इस तरह के प्रोजेक्ट के लिए यह इसके लायक है।
मुझे यह पता लगाना होगा कि हमारे कोड के कौन से हिस्से हमारे यूनिट-टेस्ट द्वारा कवर नहीं किए गए हैं। अगर मुझे पता था कि मेरे सिस्टम के कौन से हिस्से अनचाहे थे तो मैं नए परीक्षणों को विकसित करने के बारे में सोच सकता था जो अंततः पूर्ण परीक्षण-कवरेज के अपने लक्ष्य की ओर रुख करेंगे।
तो मैं इस प्रकार के विश्लेषण को चलाने के बारे में कैसे जा सकता हूं। मेरे लिए कौन से टूल्स उपलब्ध हैं?
मैं अजगर 2.4 का उपयोग विंडोज 32 बिट XP पर
UPDATE0:
बस स्पष्ट करने के लिए: हम एक बहुत ही व्यापक यूनिट-टेस्ट स्वीट है (प्लस एक अलग और बहुत व्यापक regtest सुइट जो के दायरे से बाहर है यह कसरत)। हमारे पास एक बहुत ही स्थिर निरंतर एकीकरण मंच है (हडसन के साथ बनाया गया है) जिसे हमारी परीक्षण सुविधा में मानक पायथन यूनिट-टेस्ट को विभाजित करने और चलाने के लिए डिज़ाइन किया गया है: कंपनी के स्पेस में बनाए गए लगभग 20 पीसी।
इस अभ्यास का उद्देश्य हमारे पायथन एकजुट सूट (केवल) सूट में किसी भी अंतराल को प्लग करना है ताकि प्रत्येक घटक में कुछ डिग्री अनियंत्रित कवरेज हो। अन्य डेवलपर्स परियोजना के गैर पायथन घटकों (जो दायरे के बाहर भी हैं) के लिए जिम्मेदारी ले रहे हैं।
"घटक" जानबूझकर अस्पष्ट है: कभी-कभी यह कक्षा होगी, दूसरी बार मॉड्यूल के पूरे मॉड्यूल या असेंबली होगी। यह एक वित्तीय अवधारणा को भी संदर्भित कर सकता है (उदाहरण के लिए एक प्रकार का वित्तीय विकल्प या कई प्रकार के विकल्प द्वारा उपयोग किए जाने वाले वित्तीय मॉडल)। इस केक को कई तरीकों से काटा जा सकता है।
"अर्थपूर्ण" परीक्षण (मेरे लिए) वे हैं जो यह सत्यापित करते हैं कि फ़ंक्शन डेवलपर मूल रूप से क्या करता है। हम शुद्ध पायथन में केवल regtests पुन: पेश नहीं करना चाहते हैं। प्रायः डेवलपर का इरादा तत्काल स्पष्ट नहीं होता है, इसलिए अस्पष्ट दिखने वाले किसी भी चीज को शोधने और स्पष्ट करने की आवश्यकता होती है और फिर इस ज्ञान को यूनिट-टेस्ट में स्थापित किया जाता है जो मूल उद्देश्य को स्पष्ट करता है।
suggegstion के लिए धन्यवाद: क्यों figleaf के बजाय इसका उपयोग करें? –
मैंने अपने जवाब में 'cover.py बनाम figleaf' स्पष्टीकरण जोड़ा। मुझे नहीं लगता कि यह वास्तव में महत्वपूर्ण है जो आप चुनते हैं। निष्पक्ष होने के लिए, मैंने उनमें से किसी का भी उपयोग नहीं किया है, हालांकि ये दो मुख्य उपकरण हैं। – Razzie
कवरेज 3 पिछली कमियों को ठीक करता है, यानी stdlib et al निष्पादित नहीं करता है। – Almad