कोड कवरेज में अत्यधिक सुधार कैसे करें?

Question

मुझे यूनिट टेस्ट के तहत विरासत आवेदन प्राप्त करने का काम सौंपा गया है। आवेदन के बारे में पहले कुछ पृष्ठभूमि: यह इन प्रमुख समस्याओं के साथ एक 600k LOC Java RCP कोड बेस है

• बड़े पैमाने पर कोड दोहराव
• कोई एनकैप्सुलेशन नहीं, अधिकांश निजी डेटा बाहर से सुलभ है, कुछ व्यावसायिक डेटा ने सिंगलटन भी बनाए हैं, इसलिए यह न केवल बाहर से बल्कि हर जगह से परिवर्तनशील है।
• कोई सार (उदाहरण के लिए कोई व्यावसायिक मॉडल, व्यावसायिक डेटा ऑब्जेक्ट [] और डबल [] []] में संग्रहीत नहीं है, इसलिए कोई OO नहीं है।

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

मुझे जल्दी से कुछ कवरेज प्राप्त करने के लिए समस्या पर हमला कैसे शुरू करना चाहिए , इसलिए मैं प्रबंधन को प्रगति दिखाने में सक्षम हूं (और वास्तव में JUnit परीक्षणों के सुरक्षा जाल से कमाई शुरू करने के लिए)? मैं प्रतिगमन परीक्षण स्वीट्स, जैसे एग्रीएटरऑन को उत्पन्न करने के लिए उपकरण नियोजित नहीं करना चाहता, क्योंकि ये परीक्षण कुछ सही होने पर परीक्षण नहीं करते हैं।

Comments

प्रतिगमन परीक्षण स्वचालित रूप से क्यों नहीं बनाते हैं, और प्रत्येक को व्यक्तिगत रूप से सत्यापित करें? इन सबको हाथ से लिखने से ज्यादा तेज होगा।

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

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

— dodgy_coder

@ डोडी_कोडर आमतौर पर सहमत होते हैं, लेकिन मुझे आशा है कि पारंपरिक क्यूए जो कुशलता से काम करता है, मुझे कुछ समय के लिए सुरक्षित करेगा।

— पीटर कोफ्लर

@dodgy_coder माइकल सी। पंख, लिगेसी कोड के साथ प्रभावी रूप से कार्य करने के लेखक ने "बिना परीक्षणों के कोड" के रूप में लिगेसी कोड को परिभाषित किया है। यह एक उपयोगी परिभाषा के रूप में कार्य करता है।

— स्टुपरयूज़र

Answer 1

मेरा मानना ​​है कि दो मुख्य कुल्हाड़ियाँ हैं जिनके साथ कोड रखा जा सकता है जब यूनिट परीक्षण शुरू करने की बात आती है: ए) कोड कितना परीक्षण योग्य है? और बी) यह कितना स्थिर है (यानी परीक्षण की तत्काल आवश्यकता है)? केवल चरम सीमाओं को देखते हुए, यह 4 श्रेणी देता है:

1. कोड जो परीक्षण और भंगुर करना आसान है
2. कोड जो परीक्षण और स्थिर करने के लिए आसान है
3. कोड जो परीक्षण और भंगुर होना कठिन है
4. कोड जो परीक्षण और स्थिर करने के लिए कठिन है

श्रेणी 1 शुरू करने के लिए स्पष्ट जगह है, जहां आप अपेक्षाकृत कम काम के साथ ज्यादा लाभ प्राप्त कर सकते हैं। श्रेणी 2 आपको अपने कवरेज स्टेटिस्टिक (मनोबल के लिए अच्छा) को जल्दी से सुधारने और कोडबेस के साथ अधिक अनुभव प्राप्त करने की अनुमति देता है, जबकि श्रेणी 3 अधिक (अक्सर निराशा होती है) काम करती है लेकिन अधिक लाभ भी देती है। जो आपको पहले करना चाहिए वह इस बात पर निर्भर करता है कि आपके लिए मनोबल और कवरेज के आंकड़े कितने महत्वपूर्ण हैं। श्रेणी 4 शायद परेशान करने लायक नहीं है।

Comments

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

— पीटर कोफ्लर

@Peter Kofler: प्रतिबद्ध हॉटस्पॉट एक अच्छा विचार है, लेकिन इस तरह के ज्ञान का सबसे मूल्यवान स्रोत डेवलपर्स होगा जिन्होंने कोड के साथ काम किया है।

— माइकल Borgwardt

@Peter - जैसे माइकल ने कहा, जिन डेवलपर्स ने कोड के साथ काम किया है। जिस किसी ने भी बड़ी मात्रा में कोडबेस के साथ काम किया है, उसे पता चल जाएगा कि उसके कौन से हिस्से से बदबू आती है। या, अगर पूरी चीज बदबू आ रही है, तो इसके कौन से हिस्से वास्तव में रीछ हैं ।

— कार्सन 63000

Answer 2

मेरे पास विरासत प्रणालियों (जावा हालांकि नहीं) पर काम करने का बहुत अनुभव है, इससे बहुत बड़ा। मुझे बुरी खबरों का वाहक बनने से नफरत है, आपकी समस्या आपकी समस्या का आकार है। मुझे संदेह है कि आपने इसे कम करके आंका है।

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

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

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

एक यथार्थवादी लक्ष्य "जब से हमने यूटी को लागू किया है, परीक्षण के तहत मॉड्यूल में दोष सम्मिलन उन लोगों के एक्स% तक गिरा है जो" यूटी के तहत नहीं हैं "(आदर्श रूप से x एक संख्या <100 है)।

Comments

+1, आप कोड की तुलना में जाने के लिए एक मजबूत मानक के बिना प्रभावी रूप से कुछ परीक्षण नहीं कर सकते।

— dan_waterworth

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

— पीटर कोफ्लर

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

— jwenting

Answer 3

मुझे यह याद दिलाया जाता है कि खलिहान के दरवाजे के बारे में चिंता न करने के बारे में जब घोड़े ने पहले से ही बोल्ट लगाया है।

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

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

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

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

Answer 4

कवरेज में सुधार करने का एक तरीका अधिक परीक्षण लिखना है।

एक और तरीका यह है कि आपके कोड में अतिरेक को कम किया जाए, इस तरह से कि वर्तमान प्रभाव में मौजूद परीक्षण निरर्थक कोड को कवर नहीं करते हैं।

कल्पना कीजिए कि आपके पास 3 कोड ब्लॉक हैं, ए, बी, और बी ', जहां बी' बी का डुप्लिकेट (सटीक या पास मिस कॉपी) है, और आपके पास टेस्ट टी के साथ ए और बी नहीं बल्कि बी 'पर कवरेज है।

यदि कोड को आधार ख को ख से ख को ख को ख को ख को 'बी' के रूप में समाप्त करने के लिए 'ख' के रूप में देखा जाता है, तो कोड का आधार अब बी, बी और बी के साथ 0, और 0 के साथ निरंकुश कोड वाले बी 0 के साथ दिखता है। वर्सा, और b0 और b'0 दोनों B की तुलना में बहुत छोटा है, और B का उपयोग करना / इनवॉइस करना।

अब प्रोग्राम की कार्यक्षमता नहीं बदली है, और न ही परीक्षण टी है, इसलिए हम टी को फिर से चला सकते हैं और इसे पारित करने की उम्मीद कर सकते हैं। अब कवर किया गया कोड a, b0 और B है, लेकिन b'0 नहीं। कोड बेस छोटा हो गया है (b'0 b से छोटा है!) और हम अभी भी कवर करते हैं जो हमने मूल रूप से कवर किया था। हमारा कवरेज अनुपात बढ़ गया है।

ऐसा करने के लिए, आपको अपने रिफैक्टरिंग को सक्षम करने के लिए b, b 'और आदर्श रूप से B को खोजने की आवश्यकता है। हमारा क्लोन टूल कई भाषाओं के लिए ऐसा कर सकता है, विशेष रूप से जावा सहित। आप कहते हैं कि आपके कोड आधार में बहुत सारे डुप्लिकेट कोड हैं; यह आपके लाभ से निपटने का एक अच्छा तरीका हो सकता है।

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