टूटी हुई पुरानी / विरासत यूनिट टेस्ट

Question

मैं एक बड़ी कंपनी के लिए काम करता हूं और हजारों जूनियर टेस्ट के साथ एक बड़े जावा एप्लिकेशन के लिए जिम्मेदार हूं। जब से मैं इस भूमिका में आया, तब से 200-300 टूटे हुए परीक्षण (संभवत: वर्षों से टूटे हुए) हैं। परीक्षण पुराने और नाजुक हैं और वे स्पेगेटी निर्भरता की गड़बड़ी हैं जो आमतौर पर लाइव सैंडबॉक्स डेटा के साथ समाप्त होते हैं।

मेरा लक्ष्य 100% उत्तीर्ण करने वाला परीक्षण है इसलिए हम बिल्ड को यूनिट टेस्ट विफलताओं पर तोड़ सकते हैं, लेकिन मैं तब तक ऐसा नहीं कर सकता जब तक कि मैं टूटे हुए परीक्षणों को संबोधित नहीं करता। मेरे पास बहुत कम बजट है क्योंकि रखरखाव बजट मुख्य रूप से समर्थन के लिए है, लेकिन मेरी टीम ने कम-लटकते फलों के परीक्षण (ज्यादातर कॉन्फ़िगरेशन / स्थानीय संसाधन मुद्दों) की पहचान की है और तय किया है और हम 30-40 वास्तव में बदसूरत परीक्षणों के लिए नीचे हैं।

सर्वोत्तम अभ्यास पर कुछ राय क्या है? मुझे नहीं लगता कि परीक्षण मूल्यवान हैं, लेकिन मुझे यह भी पता नहीं है कि वे क्या परीक्षण कर रहे हैं या वे खुदाई के बिना काम क्यों नहीं करते हैं, जिसमें समय और पैसा लगता है जो हमारे पास शायद नहीं है।

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

सबसे अच्छा तरीका क्या होगा?

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

Comments

निश्चित रूप से सहमत हैं कि आपको 30-40 बदसूरत परीक्षणों से छुटकारा पाना चाहिए। हालाँकि, "अगर हमारे पास एक रखरखाव / रिफलेक्टिंग विंडफॉल है तो हम उन्हें फिर से उठा पाएंगे" इच्छाधारी सोच की तरह लगता है। मुझे यकीन नहीं है कि उन्हें कम-प्राथमिकता वाले आइटम के रूप में प्रलेखित करने का कोई वास्तविक लाभ नहीं है क्योंकि ऐसी वस्तुओं को कभी कार्रवाई नहीं करने की आदत है।

— डेविड अर्नो

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

यह किसी चीज़ का डुप्लिकेट हो सकता है, लेकिन यह सवाल नहीं है। यह कैसे नाजुक इकाई परीक्षण लिखने से बचने के बारे में नहीं पूछ रहा है, लेकिन पहले से ही लिखित इकाई परीक्षणों के साथ विरासत में मिली कोडबेस को कैसे प्रबंधित किया जाए जो विफल हो रहा है।

लगता है कि आप पहले से ही अपने समाधान मिल गया है।

— डॉक ब्राउन

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

Answer 1

मैं जो करता हूं, वह पहले उन परीक्षणों को निष्क्रिय करता है जो विफल हो रहे हैं और हमेशा-विफल रहे हैं।

यह एक परीक्षण विफल मामलों बनाओ।

जैसा कि आप जांच करते हैं कि आप उन लोगों से पूछ सकते हैं जो आपकी कंपनी के साथ उनके बारे में लंबे समय तक रहे हैं, उनके बारे में बहुत से जनजातीय ज्ञान हो सकते हैं जो आप दस्तावेज़ / कैप्चर कर सकते हैं। शायद आपके VCS लॉग से। "ओह, यह परीक्षण हमेशा विफल रहा है क्योंकि हमने एक्स को अपग्रेड किया है" या अन्य जानकारी उपयोगी हो सकती है।

एक बार जब आप जानते हैं कि परीक्षण की जाने वाली कार्यक्षमता क्या है तो आप यह निर्धारित कर सकते हैं:

• क्या हमें इस बात की परवाह है कि इसका परीक्षण किया जाए
• इसका परीक्षण किया जाना कितना महत्वपूर्ण है

और फिर एक प्राथमिकता सूची बनाएं।

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

Comments

मुझे परीक्षणों को निष्क्रिय करने का विचार पसंद है, लेकिन एक रूढ़िवादी वातावरण छोटे वृद्धिशील चालों को पसंद कर सकता है। मुझे लगता है कि यह आपकी फर्म पर निर्भर करता है?

— हारून हॉल

@AaronHall - मुझे लगता है कि अगर आप अपने तत्काल कोड परिवर्तन की जरूरतों (फिक्स और एन्हांसमेंट) को देखते हैं और उनके साथ जुड़े किसी भी टूटे हुए परीक्षणों की पहचान करते हैं, तो आप इन सभी को चालू कर सकते हैं, परीक्षणों का मूल्यांकन कर सकते हैं और ठीक कर सकते हैं, समझ के साथ अपने कोडिंग परिवर्तन कर सकते हैं। वे परीक्षण या तो पास हो जाते हैं, ठीक हो जाते हैं या हटा दिए जाते हैं।

— जेफओ

Answer 2

मैं निम्नलिखित कार्य करूंगा:

1. यह निर्धारित करने का प्रयास करना कि विफल परीक्षण क्या मान्य करने का प्रयास कर रहे हैं।

2. ट्राइएज - अगर कुछ परीक्षण दुनिया की (पुरानी) स्थिति जैसी महत्वहीन चीजों का परीक्षण करने की कोशिश कर रहे हैं, तो उन्हें हटा दें। यदि आप महसूस करते हैं कि उनमें से कुछ महत्वपूर्ण को मान्य करने की कोशिश कर रहे हैं, तो यह निर्धारित करने का प्रयास करें कि क्या वे परीक्षण सही ढंग से कर रहे हैं। यदि वे गलत तरीके से परीक्षण कर रहे हैं, तो उन्हें सही तरीके से परीक्षण करें।

3. अपने उत्पादन कोड के साथ जो कुछ भी गलत है उसे ठीक करें, अब आपके पास अच्छे परीक्षण हैं।

लेखांकन को याद रखें, कोड की प्रत्येक पंक्ति एक देयता है, लेकिन संपत्ति के रूप में गलत तरीके से मूल्यवान हो सकती है। deleteकुंजी अपने फर्म के लिए मूल्य का एक बहुत बना सकते हैं।

Comments

एक टीम-शैली ट्राइएज विचार बहुत अच्छा है!

अच्छे विचार हैं, लेकिन ओपी ने पहले ही कहा कि उनके पास कोई भी भारी विश्लेषण करने के लिए कोई संसाधन नहीं है, इसलिए दुर्भाग्य से वह उनका उपयोग नहीं कर पाएंगे।

— TMN

ट्राइएज सीमित संसाधनों को राशन देने के बारे में है जहां वे सबसे अधिक मूल्य बनाएंगे। ट्रायएज और सॉफ्टवेयर के विषय पर यहाँ एक प्रासंगिक ब्लॉग पोस्ट है: softwaretestingclub.com/profiles/blogs/…

— आरोन हॉल

Answer 3

200-300 टूटे हुए परीक्षण (वर्ष के लिए टूटा हुआ)।

आउच! मुझे एक बार इसी तरह की स्थिति का सामना करना पड़ा, लेकिन 7 परीक्षणों की तरह असफलता के साथ जहां टीम ने इस तथ्य को नजरअंदाज करना शुरू कर दिया कि वे "हमेशा क्रंच" मानसिकता के कारण महीनों तक असफल रहे।

मेरा लक्ष्य 100% उत्तीर्ण करने वाला परीक्षण है इसलिए हम बिल्ड को यूनिट टेस्ट विफलताओं पर तोड़ सकते हैं, लेकिन मैं तब तक ऐसा नहीं कर सकता जब तक कि मैं टूटे हुए परीक्षणों को संबोधित नहीं करता।

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

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

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

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

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

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

Answer 4

एक तरह से आप भाग्यशाली हैं। यह बेहतर है कि ऐसे परीक्षण हों जो असफल हों और उन्हें (वे आपको कम से कम यह चेतावनी देते हैं कि कुछ गलत है) पास होने वाले परीक्षणों की तुलना में (और जो आपको सुरक्षा की झूठी भावना देते हैं)।
बेशक, यदि आपके पास पूर्व है, तो इसकी संभावना है कि आपके पास बाद वाला भी हो (इसलिए परीक्षण जो पास हो लेकिन असफल होना चाहिए)।

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

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

Answer 5

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

इन परीक्षणों को दूर फेंक दें और पीछे मुड़कर न देखें। यदि वे वर्षों से असफल रहे हैं और अब तक उन्हें संबोधित नहीं किया गया है तो वे प्राथमिकता नहीं हैं।

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

यदि कोई जनजातीय ज्ञान नहीं है, तो आपको और आपकी टीम को तर्क का स्वामित्व लेना होगा। असफल परीक्षण सहायक से अधिक भ्रामक हो सकते हैं - दुनिया आगे बढ़ सकती है।

नए परीक्षण बनाएं जो प्रासंगिक हों और बढ़िया कोड लिखने के साथ हों।