मौजूदा कोड के लिए टेस्ट लिखना


68

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

  • क्या परीक्षण एक अच्छा विचार है?
  • यदि हां, तो कोई इस तरह से कैसे शुरू करेगा?

संपादित करें

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

मुझे नहीं लगता कि एक विरासत प्रणाली के लिए लेखन परीक्षण पर विचार करने में मैं यहाँ अकेला हूँ। मैं मेट्रिक्स रखने जा रहा हूं कि कितना समय बिताया है और कितनी बार नए परीक्षण समस्याओं को पकड़ते हैं (और कितनी बार वे नहीं करते हैं)। मैं वापस आऊंगा और अपने परिणामों के साथ इसे अभी से अपडेट करूंगा।

निष्कर्ष

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


10
परीक्षण जोड़ने से मौजूदा कोड नहीं टूटेगा।
बजे डैन पिचेलमैन

30
@DanPichelman आप एक अनुभवी कभी नहीं किया है schroedinbug एक प्रोग्राम है जो जब तक किसी स्रोत को पढ़ने या एक असामान्य तरीका नोटिस कि यह काम किया जाना चाहिए था कभी नहीं, जिस पर तुरंत कार्यक्रम बात में कार्यक्रम का उपयोग कर प्रकट नहीं होता है में एक डिजाइन या कार्यान्वयन बग "- तय होने तक हर किसी के लिए काम करना बंद कर देता है। ”

8
@ मिचेल्ट अब जब आप इसका उल्लेख करते हैं, तो मुझे लगता है कि मैंने उनमें से एक या दो को देखा है। मेरी टिप्पणी को पढ़ना चाहिए "परीक्षणों को जोड़ना आमतौर पर मौजूदा कोड को नहीं तोड़ेगा"। धन्यवाद
दान Pichelman

3
केवल उन चीजों के इर्द-गिर्द परीक्षण लिखें, जिन्हें आप रिफ्लेक्टर या बदलना चाहते हैं।
स्टीवन एवर्स

3
"लिगेसी कोड के साथ प्रभावी रूप से कार्य करना" पुस्तक की जाँच करें: amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/… , माइकल फ़ेयर्स किसी भी विरासत कोड को संशोधित करने से पहले परीक्षण लिखने का सुझाव देते हैं।
स्कारैब

जवाबों:


68

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

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

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

आमतौर पर इस प्रकार के कोडबेस को संभालने का तरीका है कि नए कोड के लिए परीक्षण और पुराने कोड को फिर से व्यवस्थित करने के लिए तब तक लिखा जाए जब तक कि विरासत कोडबेस पूरी तरह से रिफलेक्ट न हो जाए।

इसके अलावा देखना


11
लेकिन, टीडीडी के बिना भी, यूनिट टेस्ट रिफैक्टरिंग करते समय उपयोगी होते हैं।
pdr

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

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

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

3
बस यह उल्लेख करना पसंद करते हैं कि 100% कोड कवरेज का मतलब यह नहीं है कि आपका कोड 100% सही ढंग से काम कर रहा है। आपके पास परीक्षण की गई विधि के लिए कोड की प्रत्येक पंक्ति हो सकती है लेकिन सिर्फ इसलिए कि यह value1 के साथ काम करती है इसका मतलब यह नहीं है कि यह value2 के साथ काम करने की गारंटी है।
ryanzec

35

हां, परीक्षण जोड़ना निश्चित रूप से एक अच्छा विचार है।

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

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

मैं कुछ अच्छे, विस्तृत सलाह के लिए माइकल फेदर की पुस्तक, लिगेसी कोड के साथ प्रभावी ढंग से काम करने की सलाह दूंगा।


10
+1। यदि आप दस्तावेज़ीकरण के आधार पर परीक्षण लिखते हैं, तो आपको कार्य कोड और प्रलेखन के बीच कोई विसंगतियां पता चलेंगी, और यह अमूल्य है।
कार्ल मैनस्टर

1
परीक्षण जोड़ने का एक अन्य कारण: जब एक बग पाया जाता है, तो आप आसानी से भविष्य के प्रतिगमन परीक्षण के लिए एक परीक्षण मामला जोड़ सकते हैं।

यह रणनीति मूल रूप से (नि: शुल्क) edX ऑनलाइन पाठ्यक्रम CS169.2x में विरासत कोड के बारे में उल्लिखित एक है। जैसा कि शिक्षकों ने इसे पुस्तक में अध्याय 9 में "ग्राउंड ट्रुथ विथ कैरेक्टरलाइज़ेशन टेस्ट" की स्थापना के बारे में बताया है: Beta.saasbook.info/table-of-contents
FGM

21

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

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

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

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


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

8

क्या परीक्षण एक अच्छा विचार है?

बिल्कुल, हालांकि मुझे यह विश्वास करना थोड़ा मुश्किल है कि कोड साफ है और अच्छी तरह से काम कर रहा है और आधुनिक तकनीकों का उपयोग कर रहा है और बस कोई इकाई परीक्षण नहीं है। क्या आप वाकई एक अलग समाधान में नहीं बैठे हैं?

वैसे भी, यदि आप कोड का विस्तार / रखरखाव करने जा रहे हैं तो सच्ची इकाई परीक्षण उस प्रक्रिया के लिए अमूल्य हैं।

यदि हां, तो कोई इस तरह से कैसे शुरू करेगा?

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

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


7
"क्या आप सुनिश्चित हैं कि वे एक अलग समाधान में नहीं बैठे हैं?" बहुत अच्छा सवाल है। मुझे उम्मीद है कि ओपी इसे नजरअंदाज नहीं करेगा।
डेन पीचेलमैन

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

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

3

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

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


क्या आप वास्तव में एक प्रोग्राम में असफल परीक्षण जोड़ सकते हैं जो अच्छी तरह से काम कर रहा है (ओपी कहते हैं)?
MarkJ

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

@ बर्नार्ड - या, परीक्षण आपकी गलतफहमी को उजागर कर सकते हैं कि कोड क्या करना चाहिए। तथ्य के बाद लिखे गए टेस्ट मूल इरादों को सही ढंग से संलग्न नहीं करने के जोखिम को चलाते हैं।
Dan Pichelman

@DanPichelman: सहमत हैं, लेकिन इससे किसी भी परीक्षण को लिखने से हतोत्साहित नहीं होना चाहिए।
बर्नार्ड

यदि और कुछ नहीं है, तो यह इंगित करेगा कि कोड रक्षात्मक रूप से नहीं लिखा गया है।
रोबी डे

3

ठीक है, मैं इसके विपरीत राय देने जा रहा हूं…।

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

वैसे भी, मैं कोई भी इकाई परीक्षण नहीं जोड़ूंगा।

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


2

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.