इकाई परीक्षणों को जोड़ने से प्रसिद्ध विरासत कोड के लिए समझ में आता है?


21
  • मैं TDD अर्थों में इकाई परीक्षणों के बारे में बात कर रहा हूँ । (स्वचालित रूप से "एकीकरण" नहीं है, या आप इसे परीक्षण के लिए क्या पसंद करते हैं।)
  • लिगेसी कोड जैसे: (C ++) कोड बिना टेस्ट के। (देखें: लिगेसी कोड के साथ माइकल फेदर्स का प्रभावी ढंग से काम करना )
  • लेकिन यह भी विरासत कोड: जैसे कि हमारी टीम पिछले 10-5 वर्षों से काम कर रही है, इसलिए हमें अक्सर इस बात का काफी अंदाजा होता है कि कुछ बदलने के लिए चीजों को कहां रखा जाए।
  • हम करते हैं के लिए इकाई परीक्षण जगह में (Boost.Test के माध्यम से) है कुछ मॉड्यूल है कि बाद में आया था या इकाई परीक्षण (सामान्य एप्लिकेशन विशिष्ट कंटेनर, स्ट्रिंग-सामान, नेटवर्क सहायकों, आदि) के लिए एक "प्राकृतिक" फिट किया गया है
  • हमारे पास अभी तक स्वचालित स्वीकृति परीक्षण नहीं हैं।

अब, हाल ही में मुझे 3 नए उपयोगकर्ता-सामना करने वाली सुविधाओं को लागू करने के लिए "खुशी" मिली।

उनमें से प्रत्येक ने मुझे बदलने के लिए आवश्यक कोड भागों के साथ गति करने के लिए लगभग 1-2 घंटे का समय लिया, (थोड़ा) कोड को लागू करने के लिए 1-2 घंटे मुझे बदलने की ज़रूरत थी और ऐप को सुनिश्चित करने के लिए 1-2 घंटे और चाहिए सही ढंग से बाद में भाग गया और यह करना चाहिए था।

अब, मैंने वास्तव में थोड़ा कोड जोड़ा है। (मुझे लगता है कि प्रत्येक सुविधा के लिए एक विधि और कुछ कॉल लाइनें हैं।)

इस कोड को फैक्टरिंग ( WEWLC में सुझाए गए किसी भी तरीके के माध्यम से ), ताकि एक यूनिट टेस्ट से समझ में आए (और पूरी तरह से ज्ञान नहीं है) आसानी से 2-4 घंटे ले लिया होगा , यदि अधिक नहीं। इससे प्रत्येक सुविधा के लिए 50% -100% समय जुड़ जाएगा, जिसमें कोई तात्कालिक लाभ नहीं होगा

  1. कोड के बारे में कुछ भी समझने के लिए मुझे यूनिट टेस्ट की आवश्यकता नहीं थी
  2. मैन्युअल परीक्षण कार्य की एक ही राशि है, क्योंकि मुझे अभी भी परीक्षण करने की आवश्यकता है यदि कोड सही ढंग से बाकी ऐप में एकीकृत है।

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

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

क्या यह दृढ़ता से युग्मित विरासत कोड के लिए कुछ विशिष्ट है? क्या मैं आलसी हूं / क्या हम एक टीम के रूप में गलत प्राथमिकताएं निर्धारित करते हैं? या मैं विवेकपूर्ण हूं, केवल सामान का परीक्षण कर रहा हूं जहां ओवरहेड बहुत अधिक नहीं है?


क्या होगा अगर कुछ अन्य विभाग आपके "प्रसिद्ध विरासत कोड" को संभाल लेंगे? वहाँ के लोग इसके साथ क्या करेंगे?
एलेक्स थिओडोरिडिस

जवाबों:


18

आपको इन स्थितियों के बारे में व्यावहारिक होना चाहिए। हर चीज का एक व्यावसायिक मूल्य होता है, लेकिन व्यवसाय को यह मानने के लिए आपको भरोसा करना होगा कि तकनीकी कार्य का मूल्य क्या है। हां, यूनिट टेस्ट करवाने का हमेशा एक फायदा होता है, लेकिन क्या वह फायदा काफी है जो खर्च किए गए समय को सही ठहराने के लिए काफी है?

मैं हमेशा नए कोड पर बहस करूंगा लेकिन, विरासत कोड पर, आपको एक निर्णय कॉल करना होगा।

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

अंगूठे का नियम: हमेशा अपने बारे में सोचें, " क्या मैं मानता हूं कि इस तकनीकी कार्य से व्यवसाय को अधिक लाभ होता है, जो मुझे लगता है कि मुझे उस नौकरी से ज्यादा करना चाहिए जो उन्होंने मांगी थी जिसके परिणामस्वरूप देरी हो रही है? "


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

2
"मैं हमेशा नए कोड पर बहस करूंगा" ... "नया कोड" एक विरासत कोडबेस या "नया नया कोड" में? :-)
मार्टिन बा

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

10

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

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

यदि आप चाहते हैं कि आपकी परियोजना जीवित रहे, तो आपको इसे परिवर्तनों के लिए तैयार करना होगा।


3

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

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


1
लेकिन, लेकिन, लेकिन! :-) नई सुविधा को लागू करने के लिए आवश्यक समय में 100% वृद्धि के लिए अनुवाद करना चाहिए । यह बाद की सुविधाओं को लागू करने के लिए आवश्यक समय को कम नहीं करता है। यह हो सकता है जब सामान को बदलने की जरूरत के समय में कमी।
मार्टिन बा

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

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

1
@ काज़ - "एक स्वचालित परीक्षण लिखकर" के साथ "हाथ से" बदलना "समय में 100% वृद्धि नहीं है। अक्सर, मुझे लगता है कि यह उसी समय के बारे में है।" - YMMV, लेकिन मेरे कोडबेस के लिए, यह स्पष्ट रूप से गलत है (जैसा कि प्रश्न में निर्धारित किया गया है)।
मार्टिन बा

3
@Kaz: I :-) का मतलब क्या था: एक इकाई परीक्षण मेरे कोड को अलगाव में परीक्षण करता है। अगर मैं एक इकाई परीक्षण नहीं लिखता हूँ तो मैं अलगाव में कोड का परीक्षण नहीं करता हूँ, लेकिन केवल अगर कोड को सही ढंग से कहा जाता है और ऐप में वांछित परिणाम उत्पन्न करता है। यह दो बिंदु (जिसे सही ढंग से कहा जाता है और ऐप-ऑफ-व्हाट्स-इट-टू) मुझे वैसे भी (मैन्युअल रूप से) परीक्षण करना होगा और एक इकाई परीक्षण द्वारा कवर नहीं किया जाएगा। और इकाई परीक्षण इन दो बिंदुओं को कवर नहीं करेगा, लेकिन अलगाव में मेरे कार्य का "परीक्षण" करेगा। (और यह यूनिट-परीक्षण-परीक्षण अतिरिक्त होगा और जहां तक ​​मैं देख सकता हूं, तब तक कुछ भी ऑफसेट नहीं होगा।)
मार्टिन बा

2

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

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

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


1

परीक्षण नहीं करने के इन छोटे तर्कसंगत निर्णयों के सभी एक अपंग तकनीकी ऋण का निर्माण कर रहे हैं जो किसी को छोड़ने पर आपको वापस आ जाएगा और किसी नए किराए पर आने और गति प्राप्त करने के लिए।

हां, यूनिट परीक्षणों को लिखने के लिए एक और 2-3 घंटे का समय लग सकता है, लेकिन यदि कोड को परीक्षण से वापस भेज दिया जाता है, तो आपको मैन्युअल रूप से सब कुछ फिर से परीक्षण करना होगा, और अपने परीक्षण को फिर से दस्तावेज़ करना होगा - आप ऐसा नहीं करते हैं? अन्यथा किसी को कैसे पता चलता है कि आपने क्या परीक्षण किया और आपने किन मूल्यों का उपयोग किया?

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

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

हालाँकि, यदि आप जानते हैं कि कोड को एक दो साल में ही रिटायर कर दिया जाएगा, तो मैंने कहा है कि आप बदलाव करेंगे क्योंकि आप कोड में परीक्षण नहीं करेंगे और यह कभी वापस भुगतान नहीं करेगा।


"और अपने परीक्षण का दस्तावेज़, फिर से - आप ऐसा करते हैं न?" - {निंदक टोपी लगाना:} बिल्कुल नहीं। हम डेवलपर परी भूमि में नहीं हैं। सामान कार्यान्वित और परीक्षण किया जाता है और भेज दिया जाता है। बाद में यह टूट जाता है और तय हो जाता है और परीक्षण और भेज दिया जाता है।
मार्टिन बा

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

2
mcottle - आपको एक महत्वपूर्ण बिंदु याद आ रहा है । इकाई परीक्षण समाप्त सुविधा के "मैनुअल कार्यक्षमता परीक्षण" करने में लगने वाले समय को कम नहीं करेगा । मुझे अभी भी उन सभी संवादों के माध्यम से क्लिक करना है, जिनमें संभावित इनपुट के विवेकपूर्ण सबसेट के साथ शामिल है, यह सुनिश्चित करने के लिए कि यह क्या करना है, जैसा कि वास्तविक तैयार ऐप करता है। (मैं मानता हूं कि सैद्धांतिक रूप से इकाई परीक्षण इस मैनुअल परीक्षण चक्र को केवल एक लूप तक सीमित करने में मदद कर सकता है यदि इकाई परीक्षण यह सुनिश्चित करता है कि मुझे मैनुअल परीक्षण के दौरान कोई स्पष्ट समस्या नहीं मिलेगी।)
मार्टिन बा

0

इकाई परीक्षणों का मूल्य केवल विकसित होने पर एक नई सुविधा का परीक्षण करने में झूठ नहीं होता है। यूनिट परीक्षणों का लाभ ज्यादातर भविष्य में प्राप्त होता है।

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

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


1
"इकाई परीक्षणों के बिना आपके पास यह सुनिश्चित करने के लिए कोई अन्य साधन नहीं है कि आपकी सुविधा अनजाने में टूटी नहीं थी, तब भी जब वह सुविधा परिवर्तित नहीं हुई थी।" - यूनिट परीक्षण मदद नहीं करेगा। वास्तव में सुनिश्चित करने के लिए , मुझे स्वचालित एकीकरण / स्वीकृति परीक्षण करना होगा।
मार्टिन बा

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