क्या यह पूरी तरह से रिफैक्टरिंग के लिए समय नहीं होने पर विरासत कोड के लिए परीक्षण लिखने के लिए समझ में आता है?

72

मैं आमतौर पर लिगेसी कॉड ई के साथ प्रभावी रूप से कार्य करने वाली पुस्तक की सलाह का पालन करने की कोशिश करता हूं । मैं निर्भरता को तोड़ता हूं, कोड के कुछ हिस्सों को @VisibleForTesting public staticविधियों और नई कक्षाओं में ले जाता हूं ताकि कोड (या कम से कम कुछ हिस्सा) परीक्षण योग्य बनाया जा सके। और मैं यह सुनिश्चित करने के लिए परीक्षण लिखता हूं कि जब मैं संशोधित कर रहा हूं या नए फ़ंक्शन जोड़ रहा हूं तो मैं कुछ भी नहीं तोड़ता।

एक सहयोगी का कहना है कि मुझे ऐसा नहीं करना चाहिए। उनका तर्क:

मूल कोड पहली बार में ठीक से काम नहीं कर सकता है। और इसके लिए परीक्षण लिखने से भविष्य में सुधार और संशोधन कठिन हो जाते हैं क्योंकि देवों को परीक्षणों को भी समझना और संशोधित करना पड़ता है।
अगर यह कुछ तर्क के साथ GUI कोड है (~ 12 लाइनों, 2-3 if / else ब्लॉक, उदाहरण के लिए), एक परीक्षण मुसीबत के लायक नहीं है क्योंकि कोड बहुत तुच्छ से शुरू होता है।
इसी तरह के खराब पैटर्न कोडबेस के अन्य हिस्सों में भी मौजूद हो सकते हैं, (जो मैंने अभी तक नहीं देखा है, मैं नया नहीं हूँ); उन सभी को एक बड़ी रीफैक्टरिंग में साफ करना आसान होगा। तर्क को बाहर निकालना इस भविष्य की संभावना को कम कर सकता है।

क्या हमें परीक्षण योग्य भागों को निकालने और परीक्षण लिखने से बचना चाहिए, अगर हमारे पास पूर्ण रीफैक्टरिंग का समय नहीं है? क्या इसका कोई नुकसान है जो मुझे विचार करना चाहिए?

unit-testing refactoring legacy-code

— IS4
स्रोत

29

लगता है कि आपका सहकर्मी सिर्फ बहाने पेश कर रहा है क्योंकि वह उस तरह से काम नहीं करता है। लोग कभी-कभी इस तरह का व्यवहार करते हैं कि वे अपने काम करने के तरीके को बदलने के लिए बहुत दृढ़ हो जाते हैं।

— डॉक्टर ब्राउन

3

क्या एक बग के रूप में वर्गीकृत किया जाना चाहिए यह एक सुविधा में बदल कोड के अन्य भागों द्वारा पर भरोसा किया जा सकता है

— शाफ़्ट सनकी

1

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

— केशलैम

6

पहला बिंदु प्रफुल्लित करने वाला है - "इसका परीक्षण मत करो, यह छोटी गाड़ी हो सकती है।" ठीक है, हाँ? फिर यह जानना अच्छा है कि - या तो हम इसे ठीक करना चाहते हैं या हम नहीं चाहते हैं कि कोई भी वास्तविक व्यवहार को बदल दे, जो कुछ डिजाइन युक्ति ने कहा है। किसी भी तरह से, (स्वचालित प्रणाली में परीक्षणों को चलाना और चलाना) फायदेमंद है।

— क्रिस्टोफर Creutzig

3

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

— जूलिया हैवर्ड

100

यहां मेरी व्यक्तिगत अवैज्ञानिक धारणा है: सभी तीन कारण व्यापक लेकिन झूठे संज्ञानात्मक भ्रम की तरह लगते हैं।

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

— किलियन फोथ
स्रोत

23

+1 के लिए "वस्तुतः सभी गंभीर त्रुटियां होती हैं क्योंकि लोगों को लगता था कि वे वास्तव में कुछ बेहतर समझ गए हैं।"

— रेम

बिंदु 1 - बीडीडी के साथ , परीक्षण स्वयं दस्तावेज हैं ...

— रॉबी डी

2

जैसा कि @ guillaume31 बताते हैं, लेखन परीक्षणों के मूल्य का एक हिस्सा यह प्रदर्शित करता है कि कोड वास्तव में कैसे काम करता है - जो विनिर्देश (एस) के अनुसार हो सकता है या नहीं भी हो सकता है। लेकिन यह कल्पना हो सकती है कि यह "गलत" है: व्यावसायिक आवश्यकताएं बदल सकती हैं और कोड नई आवश्यकताओं को दर्शाता है लेकिन कल्पना नहीं करता है। बस यह मानते हुए कि कोड "गलत है" अत्यधिक सरलीकृत है (बिंदु 1 देखें)। और फिर से परीक्षण आपको बताएंगे कि कोड वास्तव में क्या करता है, न कि कोई ऐसा क्या सोचता / कहता है जो यह करता है (बिंदु 2 देखें)।

— डेविड

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

— फ्रैंक होपकिंस

50

कुछ विचार:

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

मैं सहमत हूँ कि शुद्ध जीयूआई कोड का परीक्षण करना कठिन है और शायद " वर्किंग इफ़ेक्टली ... " -स्टाइल रीफैक्टरिंग के लिए अच्छा फिट नहीं है । हालांकि, इसका मतलब यह नहीं है कि आपको ऐसे व्यवहार को नहीं निकालना चाहिए जिसमें GUI परत में कुछ भी नहीं है और निकाले गए कोड का परीक्षण करें। और "12 लाइनें, 2-3 यदि / अन्यथा ब्लॉक" तुच्छ नहीं है। कम से कम सशर्त तर्क के साथ सभी कोड का परीक्षण किया जाना चाहिए।

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

चीजों को उत्तरोत्तर छोटे रिफ्लेक्टरिंग के साथ उत्तरोत्तर बेहतर बनाते हुए "भविष्य की संभावनाओं को कम नहीं" कर रहा है, यह उन्हें सक्षम कर रहा है - दलदली जमीन को मजबूत करना जहां आपका आवेदन निहित है। आपको इसे जरूर करना चाहिए।

— guillaume31
स्रोत

5

+1 के लिए "परीक्षण आप लिखते हैं कि कार्यक्रम के वर्तमान व्यवहार का परीक्षण करें "

— डेविड

17

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

— रोरी हंटर
स्रोत

सच में अफसोस की बात। हमारे पास कुछ ऐसे स्पष्ट कीड़े हैं जो किनारे के मामलों में प्रकट होते हैं जिन्हें हम ठीक नहीं कर सकते क्योंकि हमारे ग्राहक शुद्धता पर वरीयता पसंद करते हैं। (वे डेटा-एकत्रित करने वाले कोड के कारण कारण हैं कि रिपोर्टिंग कोड को ध्यान में रखने की अनुमति नहीं है, जैसे कि फ़ील्ड की एक श्रृंखला में एक फ़ील्ड को खाली छोड़ देना)

— इजाका

14

किलियन का जवाब सबसे महत्वपूर्ण पहलुओं को शामिल करता है, लेकिन मैं अंक 1 और 3 पर विस्तार करना चाहता हूं।

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

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

हालांकि, इसके लिए यह आवश्यक है कि परीक्षण को एक विशेषाधिकार के रूप में परीक्षण न करने वाले व्यवहार के रूप में प्रलेखित किया जाए।

बिंदु 3 पर कुछ विचार, भी: इस तथ्य के अलावा कि "बड़ा झपट्टा" शायद ही कभी वास्तव में होता है, एक और बात यह भी है: यह वास्तव में आसान नहीं है। आसान होने के लिए, कई शर्तों को लागू करना होगा:

प्रतिपक्षी होने वाले एंटीपार्टर्न को आसानी से मिल जाने की आवश्यकता है। क्या आपके सभी एकल नाम हैं XYZSingleton? क्या उनका उदाहरण गटर हमेशा कहा जाता है getInstance()? और आप अपनी अत्यधिक गहरी पदानुक्रम कैसे पाते हैं? आप अपने देव वस्तुओं की खोज कैसे करते हैं? इन्हें कोड मेट्रिक्स विश्लेषण की आवश्यकता होती है और फिर मैन्युअल रूप से मेट्रिक्स का निरीक्षण करना होता है। या आप बस उन पर ठोकर खाते हैं जैसे आप काम करते हैं, जैसा आपने किया था।
Refactoring को यांत्रिक होना चाहिए। ज्यादातर मामलों में, रिफैक्टरिंग का कठिन हिस्सा मौजूदा कोड को अच्छी तरह से समझ रहा है कि इसे कैसे बदलना है। सिंगलेट्स फिर से: यदि सिंगलटन चला गया है, तो आपको इसके उपयोगकर्ताओं को आवश्यक जानकारी कैसे मिलेगी? इसका मतलब अक्सर स्थानीय कॉलगर्ल को समझना होता है ताकि आप जान सकें कि जानकारी कहाँ से प्राप्त की जाए। अब क्या आसान है: अपने ऐप में दस सिंगललेट्स की खोज करना, प्रत्येक के उपयोग को समझना (जिसमें 60% कोडबेस को समझने की आवश्यकता होती है), और उन्हें रिप करना? या जो कोड आप पहले से ही समझ रहे हैं (क्योंकि आप अभी उस पर काम कर रहे हैं) ले रहे हैं और वहां इस्तेमाल किए जा रहे सिंगलेट्स को रिप कर रहे हैं? यदि रिफैक्टरिंग इतना यांत्रिक नहीं है कि उसे आसपास के कोड के बारे में कोई जानकारी नहीं है, तो उसे बंद करने में कोई फायदा नहीं है।
रिफैक्टरिंग को स्वचालित करने की आवश्यकता है। यह कुछ हद तक राय आधारित है, लेकिन यहाँ जाता है। थोड़ा सा refactoring मजेदार और संतोषजनक है। बहुत सारे रिफैक्टरिंग थकाऊ और उबाऊ हैं। कोड के टुकड़े को छोड़कर आपने अभी एक बेहतर स्थिति में काम किया है, इससे पहले कि आप और अधिक दिलचस्प सामग्री पर आगे बढ़ें, आपको एक अच्छा, गर्म महसूस होगा। एक संपूर्ण कोड बेस को रिफलेक्टर करने की कोशिश आपको निराश और गुस्सा करने वाले प्रोग्रामर को गुस्सा दिलाएगी जिसने इसे लिखा था। यदि आप एक बड़ा झपट्टा फिर से करना चाहते हैं, तो यह काफी हद तक स्वचालित होना चाहिए ताकि हताशा को कम किया जा सके। यह एक तरह से, पहले दो बिंदुओं का एक मेल है: आप केवल रिफैक्टरिंग को स्वचालित कर सकते हैं यदि आप खराब कोड (यानी आसानी से पाए जाने वाले) को ढूंढकर स्वचालित कर सकते हैं, और इसे बदल सकते हैं (यानी मैकेनिकल)।
एक बेहतर व्यावसायिक मामले के लिए धीरे-धीरे सुधार होता है। बड़े झपट्टा refactoring अविश्वसनीय रूप से विघटनकारी है। यदि आप एक कोड कोड को रिफ्लेक्टर करते हैं, तो आप हमेशा उस पर काम करने वाले अन्य लोगों के साथ मर्ज संघर्ष में शामिल हो जाते हैं, क्योंकि आप सिर्फ उस विधि को विभाजित करते हैं जिसे वे पांच भागों में बदल रहे थे। जब आप एक उचित आकार के कोड को रिफलेक्टर करते हैं, तो आपको कुछ लोगों के साथ संघर्ष होता है (1-2 जब 600-लाइन मेगाफ़ंक्शन को विभाजित करते हैं, 2-4 जब देव वस्तु को तोड़ते हैं, तो 5 जब एक मॉड्यूल से सिंगलटन को निकालते हैं ), लेकिन आपके मुख्य संपादन के कारण आपको वैसे भी संघर्ष करना पड़ा होगा। जब आप एक कोडबेस-वाइड रिफैक्टिंग करते हैं, तो आप सभी के साथ संघर्ष करते हैं। यह उल्लेख नहीं करने के लिए कि यह दिनों के लिए कुछ डेवलपर्स को बाँधता है। धीरे-धीरे सुधार के कारण प्रत्येक कोड संशोधन में थोड़ा अधिक समय लगता है। यह इसे और अधिक पूर्वानुमान योग्य बनाता है, और सफाई के अलावा ऐसा कुछ दिखाई नहीं देता है जब ऐसी कोई समयावधि नहीं होती है।

— सेबस्टियन रेडल
स्रोत

12

कुछ कंपनियों में एक संस्कृति होती है, जहां वे डेवलपर्स को किसी भी समय कोड बढ़ाने के लिए अनुमति देते हैं जो सीधे अतिरिक्त मूल्य प्रदान नहीं करता है जैसे कि नई कार्यक्षमता।

मैं शायद यहाँ रूपांतरित होने का प्रचार कर रहा हूँ, लेकिन यह स्पष्ट रूप से झूठी अर्थव्यवस्था है। बाद के डेवलपर्स के लिए स्वच्छ और संक्षिप्त कोड लाभ। यह सिर्फ इतना है कि पेबैक तुरंत स्पष्ट नहीं होता है।

मैं व्यक्तिगत रूप से बॉय स्काउट प्रिंसिपल की सदस्यता लेता हूं, लेकिन अन्य (जैसा कि आपने देखा है) नहीं।

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

कुछ बदलाव दूसरों की तुलना में कम जोखिम वाले होते हैं। उदाहरण के लिए, जहां मैं वहां काम करता हूं, बहुत सारे डुप्लिकेट किए गए कोड होते हैं, जिन्हें कम से कम प्रभाव के साथ सबरूटीन में सुरक्षित रूप से खेती की जा सकती है।

अंत में, आपको एक निर्णय कॉल करना होगा कि आप कितनी दूर तक रिफलेक्टरिंग ले जाते हैं, लेकिन स्वचालित परीक्षणों को जोड़ने में निर्विवाद रूप से महत्वपूर्ण मूल्य है यदि वे पहले से मौजूद नहीं हैं।

— रोबी डी
स्रोत

2

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

— ozz

2

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

— फेज

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

— रॉबी डी

4

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

मैं तब उन भागों के लिए इकाई परीक्षण लिखूंगा जिन्हें आप बदलना चाहते हैं और हर बार जब आप परिवर्तन करना चाहते हैं तो समय के साथ आपकी इकाई परीक्षण कवरेज में वृद्धि होगी।

यह दृष्टिकोण आपको एक अच्छा विचार देता है यदि परिवर्तन सिस्टम के अन्य भागों को प्रभावित कर रहे हैं और चलिए आप किसी भी आवश्यक परिवर्तन को जल्द से जल्द करने की स्थिति में आ जाते हैं।

— jamesj
स्रोत

3

पुन: "मूल कोड ठीक से काम नहीं कर सकता है":

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

— रेम
स्रोत

1

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

— cHao

3

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

गैर-तुच्छ कोड में हमेशा कीड़े होते हैं (एक आदमी को uni से उद्धृत करना; और अगर इसमें कोई कीड़े नहीं हैं, तो यह तुच्छ है) और हमारा काम ग्राहक को खोजने से पहले उन्हें ढूंढना है। विरासत कोड में विरासत कीड़े हैं। यदि मूल कोड उस तरह से काम नहीं करता है, जैसा कि आप इसके बारे में जानना चाहते हैं, तो मेरा विश्वास करो। कीड़े ठीक हैं यदि आप उनके बारे में जानते हैं, तो उन्हें खोजने से डरो मत, यही नोट्स जारी करने के लिए हैं।

अगर मुझे ठीक से याद है कि रिफैक्टिंग किताब वैसे भी लगातार परीक्षण करने के लिए कहती है। इसलिए यह प्रक्रिया का हिस्सा है।

— RedSonja
स्रोत

3

स्वचालित परीक्षण कवरेज करें।

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

फ़्रीफ़ॉल वेब कॉमिक से मेरा एक पसंदीदा उद्धरण है: "क्या आपने कभी एक जटिल क्षेत्र में काम किया है जहाँ पर्यवेक्षक के पास तकनीकी विवरणों का केवल एक मोटा विचार है? ... तो आप जानते हैं कि आपके पर्यवेक्षक को विफल करने का सबसे अच्छा तरीका है? बिना सवाल के उसके हर आदेश का पालन करें। ”

आपके द्वारा निवेश किए जाने वाले समय को सीमित करना शायद उचित है।

— technophile
स्रोत

1

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

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

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

IntegrationTestCase1()
{
    var input = ReadDataFile("path\to\test\data\case1in.ext");
    bool validInput = ValidateData(input);
    Assert.IsTrue(validInput);

    var processedData = ProcessData(input);
    Assert.AreEqual(0, processedData.Errors.Count);

    bool writeError = WriteFile(processedData, "temp\file.ext");
    Assert.IsFalse(writeError);

    bool filesAreEqual = CompareFiles("temp\file.ext", "path\to\test\data\case1out.ext");
    Assert.IsTrue(filesAreEqual);
}

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

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

— डान नीली
स्रोत