कॉपी-एंड-पास्ट टेस्ट कोड: यह कितना बुरा है?

Question

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

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

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

EDIT: जो टूल मैं उपयोग कर रहा हूं वह सिल्कटेस्ट है, जो कि 4Test नामक एक मालिकाना भाषा में है। साथ ही, ये परीक्षण ज्यादातर विंडोज डेस्कटॉप अनुप्रयोगों के लिए हैं, लेकिन मैंने इस सेटअप के साथ-साथ वेब एप्लिकेशन का भी परीक्षण किया है।

Comments

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

— ग्लेनपेटर्सन

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

— इज़्काटा

मैंने जो कुछ भी लिखा है, उसमें परीक्षण कोड को फिर से भरने से बाहर नहीं रखा गया है ..

— साइमन व्हाइटहेड

Answer 1

कॉपी-पेस्ट और फिर संपादित किए गए परीक्षण मामले अक्सर ठीक होते हैं।

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

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

Comments

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

— joshin4colours

Answer 2

दोहराव सभी बुराई की जड़ है

यह सही है! दोहराव सभी बुराई की जड़ है । संभवत: यह उनकी पुस्तक "समयपूर्व अनुकूलन सभी बुराई की जड़ है" में नथ कह रहा था, लेकिन मुझे लगता है कि यह दोहराव है।

जब भी आप एक कार्यक्रम को देखते हैं या आप एक लिख रहे हैं और आप किसी प्रकार की पुनरावृत्ति की खोज करते हैं: इसे हटा दें! इसे तुरंत मार डालो ... जो भी हो लेकिन इससे छुटकारा पा लो !

हर बार जब मैंने किसी प्रकार की पुनरावृत्ति की शुरुआत की और वहां एक बग को ठीक करना पड़ा, तो मैं प्रतिकृति को ठीक करना भूल गया ... (डोनाल्ड नथ) तो, जब भी कोई पुनरावृत्ति होती है तो इसे केवल उतना ही हटा दें जितना आप कर सकते हैं, हैक न करें !

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

यहाँ कोड हॉरर से एक अच्छी रीडिंग है जो मुझे प्रेरित करती है - कोड पुन: उपयोग की कॉपी और पेस्ट स्कूल के लिए एक मामूली प्रस्ताव ।

Comments

"हर बार जब मैंने किसी प्रकार की पुनरावृत्ति की शुरुआत की थी और वहाँ एक बग को ठीक करना था, तो मैं प्रतिकृति को ठीक करना भूल गया ..." बिल्कुल। इसके अलावा, अगर आप c & p और आप कॉपी किए गए टेक्स्ट को अपने वर्तमान संदर्भ में समायोजित करना भूल जाते हैं, तो इससे बहुत नुकसान होगा। Bugged परीक्षण कोड इष्टतम स्थिति की तरह नहीं है, अब यह करता है?

— marktani

हाँ, मैं नथुथ से स्टेशन ले गया :)

— युसुबोव

आपने खुद को दोहराया: आपने शीर्षक और आपके परिचय वाक्य में "दोहराव सभी बुराई की जड़ है" कहकर अपने आप को दोहराया।

— थॉमस एडिंग

हाँ, मैंने ऐसा किया है कि जानबूझकर महत्व पर जोर दिया गया है और आप thats भाग को संपादित करने के लिए स्वागत कर रहे हैं :)

— युसुबोव

थॉमस ईडिंग, आपने खुद को भी दोहराया। आपने खुद को भी दोहराया) =)

— मार्कटानी

Answer 3

यह अभी भी कटौती और पेस्ट करने के लिए बहुत बुरा है। कुछ समस्याएं हैं।

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

यदि आप अपने परीक्षणों के बाहर सहायक विधियों में तर्क को अतिक्रमण नहीं कर सकते, तो आप स्वयं उन सहायक विधियों के परीक्षण नहीं लिख सकते। परीक्षण विधियों का परीक्षण लिखना आमतौर पर सार्थक बनाने के लिए कठिन होता है, क्योंकि आपको परीक्षण का परीक्षण करने के लिए अपना कोड तोड़ना पड़ता है। लेकिन आप सहायक विधियों का परीक्षण कर सकते हैं ।

यह परीक्षणों को कम पठनीय बना सकता है। कॉपी किए गए कोड का एक बड़ा ब्लॉक एक वर्णनात्मक नाम के साथ सहायक विधि के लिए कॉल से पढ़ने के लिए कठिन हो सकता है।

मैंने जो कुछ भी सूचीबद्ध किया है वह सब कुछ है जो एक समस्या हो सकती है। यदि आप पाते हैं कि उनमें से कोई भी वास्तव में एक समस्या नहीं है, तो निश्चित रूप से यह ठीक है।

Comments

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

— dwjohnston

Answer 4

मैं आपसे सहमत था। लेकिन फिर, समय के साथ, मैंने पाया कि मेरे द्वारा किए गए हर परिवर्तन (विशेषकर यूनिट परीक्षणों में DI परिवर्तन) को बदलने के लिए कई परीक्षणों की आवश्यकता थी और यह बोझिल था। अब मैं परीक्षण लिखते समय भी DRY के स्कूल की सदस्यता लेता हूं।

GUI परीक्षण के लिए, आप बार-बार कोड को कम करने के लिए PageObject पैटर्न को देखना चाह सकते हैं ।

Answer 5

मैं XUnit पैटर्न लेने की सलाह दूंगा। जब तक मैं उस किताब का लाभ उठाना शुरू नहीं कर देता, तब तक मुझे भी वही समस्या थी। वस्तु माँ ऐसा पैटर्न ध्वनियों अपने परिदृश्य के लिए सबसे उपयोगी होगा।

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

Comments

Object Mother patternसामान्य प्रारंभिक कोड के लिए +1 ।

— k3b

Answer 6

क्या लोगों को पुनरावृत्ति की कोशिश करनी चाहिए और जब वे कर सकते हैं - हाँ। लेकिन अदायगी की स्थिति पर निर्भर करता है। यह 'सर्वोत्तम अभ्यास' बहस पर वापस जा सकता है। लेकिन सवाल यह है कि इस स्थिति में आपके लिए सबसे अच्छा क्या है। हर नियम के अपवाद हैं।

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

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

Answer 7

एक बड़ी प्रक्रिया

एक विचार: ऐसा लगता है जैसे आप तरीकों को बनाकर कट-एन-पेस्ट कोड से बचने की कोशिश कर रहे हैं:

testScreen(title, fieldList, linkList, param1, param2, param3,...) {
    test that the layout at the top of the screen is correct
    test if PageTitle == title?
    for each field in fieldList:
        check that it appears in order on the screen
    for each field in linkList:
        check that it appears in order on the screen
    test if param1 is whatever...
    test if param2 is whatever...
    etc.
    test that the bottom of the screen is correct
}

कई छोटी प्रक्रियाएं (टूलकिट)

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

testScreenTop()
verifyLinks(list)
testScreenBottom()

आप अभी भी हर स्क्रीन में इन प्रक्रियाओं को काटते और चिपकाते हैं, लेकिन आप कोड के छोटे टुकड़ों को काट रहे हैं और पेस्ट कर रहे हैं और सामान्यता के उन हिस्सों को बाहर निकाल रहे हैं जो काटे नहीं जाते हैं और चिपकाए जाते हैं (प्रत्येक छोटी प्रक्रियाओं की सामग्री)।

काटो और चिपकाओ

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

स्वचालित UI परीक्षण

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

Answer 8

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

Answer 9

यह अधिकांश अन्य उत्तरों के समान है लेकिन एक गैर तकनीकी प्रबंधक को समझ सकता है।

निम्नलिखित त्रुटि परिदृश्य की कल्पना करें:

• कोई व्यक्ति डेटाबेसिबल में परिवर्तन करता है, जहां आपके कई परीक्षण निर्भर करते हैं।
• परिणाम: अचानक आपके 2933 स्वचालित परीक्षणों में से 117 विफल हो जाते हैं।

आप क्या करेंगे?

• (१) ११ fix परीक्षण ठीक करें?
• (2) 117 परीक्षाओं को हटा दें और नई कॉपी और पेस्ट के माध्यम से उन्हें फिर से लागू करें। यह (1) की तुलना में आसान हो सकता है
• (3) सामान्य कोड निकालने के लिए परीक्षणों को रिफलेक्टर करें ताकि भविष्य में आपको परीक्षणों को ठीक करने के लिए केवल एक विधि (या कुछ) को अनुकूलित करना पड़े (@pdr या @Michael Brown के उत्तर देखें)
• (4) परीक्षणों को फिर से लागू किए बिना 117 परीक्षण हटाएं

मेरे अनुभव से:

स्वचालित परीक्षण प्रबंधन शुरू करते समय "कॉपी और पेस्ट-परीक्षण" पसंद करते हैं: आपको थोड़े समय में कई परीक्षण मिलते हैं।

"त्रुटि परिदृश्यों" में से कुछ के बाद प्रबंधन पसंद करता है (4) क्योंकि "कॉपी और पेस्ट-परीक्षण" को ठीक करना इतना महंगा है।

इसे पहली जगह में ही करें (3) इतना तेज नहीं होगा, लेकिन इस बात की संभावना बढ़ जाती है कि परीक्षण बच जाएंगे