यूनिट परीक्षणों के बारे में बात करते समय "डीआरएमपी डीआरवाई नहीं" का क्या अर्थ है?

Question

मैंने किसी को यह कहते सुना कि इकाई परीक्षण (जैसे nUnit, jUnit, xUnit) होना चाहिए

नम नहीं सूखी

(जैसे इकाई परीक्षणों में "नम कोड" होना चाहिए "सूखा कोड" नहीं)

उनकी बातचीत किस बारे में हो रही है?

Comments

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

— एक्यूमेनस

DRYness कोड नेविगेशन दूरी को बढ़ाती है, जिसके परिणामस्वरूप उच्च मानसिक भार को समझने में मदद मिलती है। यह एक "सामान्य" पाठ आधारित वातावरण में है। एक प्रॉजेक्टस एडिटर कोड की ऑर्थोगोनलिटी को कम कर सकता है लेकिन हर मामले में नहीं।

— पीटर

मैं इस लेख की सलाह देता हूं: enterprisecraftsmanship.com/posts/dry-damp-unit-tests

— व्लादिमीर

Answer 1

यह एक संतुलन है, विरोधाभास नहीं

DAMP और DRY विरोधाभासी नहीं हैं, बल्कि वे एक कोड के रख-रखाव के दो अलग-अलग पहलुओं को संतुलित करते हैं । बनाए रखने योग्य कोड (कोड जो बदलना आसान है) यहां अंतिम लक्ष्य है।

DAMP (वर्णनात्मक और सार्थक वाक्यांश) कोड की पठनीयता को बढ़ावा देता है ।

कोड बनाए रखने के लिए, आपको सबसे पहले कोड को समझना होगा। इसे समझने के लिए, आपको इसे पढ़ना होगा। एक पल के लिए विचार करें कि आप पढ़ने के कोड को कितना समय देते हैं । यह बहुत है। DAMP कोड को पढ़ने और समझने के लिए आवश्यक समय को कम करके स्थिरता को बढ़ाता है।

DRY (खुद को दोहराएं नहीं) कोड की ऑर्थोगोनलिटी को बढ़ावा देता है ।

दोहराव को हटाने से यह सुनिश्चित होता है कि सिस्टम की प्रत्येक अवधारणा में कोड में एक एकल आधिकारिक प्रतिनिधित्व है। किसी एकल व्यवसाय अवधारणा के परिवर्तन से कोड में एकल परिवर्तन होता है। DRY सिस्टम के केवल उन हिस्सों को परिवर्तन (जोखिम) को अलग करके स्थिरता बनाए रखता है जिन्हें बदलना होगा।

तो, परीक्षणों में दोहराव अधिक स्वीकार्य क्यों है?

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

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

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

एक सिद्धांत के रूप में, उत्पादन कोड में DRY का पक्ष, परीक्षण कोड में DAMP का पक्ष। जबकि दोनों समान रूप से महत्वपूर्ण हैं, थोड़ी सी समझदारी से आप अपने पक्ष में संतुलन बना सकते हैं।

Comments

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

— जेसन

@ जेसन, Btw "जेसपर लुंडबर्ग भी इस विषय पर एक अच्छा ग्रंथ है" के लिए एक कड़ी है ?

— 23

@ जॉनसनर्स, आप परीक्षण डेटा बिल्डर पैटर्न का उपयोग करके उस दोहराव से बच सकते हैं: natpryce.com/articles/000714.html

— si618

DRYing आउट टेस्ट कोड में एक रहस्यमय अतिथि

— jayeff

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

— ली मैकअली

Answer 2

डेम्प - वर्णनात्मक और सार्थक वाक्यांश।

कोड पुनः उपयोग पर "DAMP not DRY" पठनीयता को महत्व देता है। परीक्षण के मामलों में DAMP not DRY का विचार यह है कि परीक्षणों को समझना आसान होना चाहिए, भले ही इसका मतलब है कि परीक्षण मामलों में कभी-कभी कोड दोहराया गया हो।

यह भी देखें कि क्या यूनिट परीक्षणों में डुप्लिकेट कोड अधिक सहनीय है? इस दृष्टिकोण के गुणों पर कुछ चर्चा के लिए।

यह डोमेन विशिष्ट भाषाओं के संबंध में जे फील्ड्स द्वारा गढ़ा गया हो सकता है ।

Comments

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

— गेराल्ड डेविस

Answer 3

"DRY" है "अपने आप को दोहराएं नहीं"

यह एक शब्द है जिसका उपयोग लोगों को पुन: प्रयोज्य कोड लिखने के लिए किया जाता है, ताकि आप बार-बार समान कोड लिखना न छोड़ें।

"डेम्प" "वर्णनात्मक और अर्थपूर्ण वाक्यांश" है।

इस शब्द का उद्देश्य आपको कोड लिखना है जो आसानी से किसी ऐसे व्यक्ति द्वारा समझा जा सकता है जो इसे देख रहा है। यदि आप इस सिद्धांत का पालन कर रहे हैं, तो आपके पास लंबे और वर्णनात्मक चर और फ़ंक्शन नाम होंगे, आदि।

Comments

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

— आंद्रेजेज डॉयल

Answer 4

नम = 'वर्णनात्मक और सार्थक वाक्यांश' - आपकी इकाई परीक्षण 'पढ़ने' में सक्षम होना चाहिए:

अनावश्यक कोड से बचने की तुलना में पठनीयता अधिक महत्वपूर्ण है।

लेख से:

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

इसका क्या अर्थ है और इसका उपयोग कहां करना है?

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

Answer 5

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

http://codeshelter.wordpress.com/2011/04/07/dry-and-damp-principles-when-developing-and-unit-testing/

Answer 6

यहां पहले से ही कई उत्तर हैं, लेकिन मैं एक और जोड़ना चाहता था क्योंकि मुझे नहीं लगता था कि वे जरूरी समझाते हैं कि वे भी कर सकते हैं।

DRY का विचार (अपने आप को दोहराएं नहीं) यह है कि आपके एप्लिकेशन कोड में आप अनावश्यक या रेप्टेटिव कोड से बचना चाहते हैं। यदि आपको कुछ ऐसा मिला है, जिसमें आपके कोड को कई बार करने की आवश्यकता होती है, तो आपको कई स्थानों पर समान कोड को दोहराने के बजाय इसके लिए एक फ़ंक्शन या वर्ग होना चाहिए।

यह एक काफी प्रसिद्ध प्रोग्रामिंग अवधारणा है।

DAMP (वर्णनात्मक और अर्थपूर्ण वाक्यांश) आपकी इकाई परीक्षणों के लिए है। यहां विचार यह है कि आपकी इकाई परीक्षण विधि के नाम लंबे और वर्णनात्मक होने चाहिए - प्रभावी रूप से छोटे वाक्य जो कि आप परीक्षण कर रहे हैं का वर्णन करते हैं।

उदाहरण के लिए: testWhenIAddOneAndOneIShouldGetTwo() { .... }

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

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

डीएएमपी और डीआरवाई एक दूसरे के विपरीत नहीं हैं - वे आपके कोड को कैसे लिखा जाता है के विभिन्न पहलुओं को कवर करते हैं - लेकिन फिर भी वे आम तौर पर एक साथ उपयोग नहीं किए जाते हैं, क्योंकि डीआरवाई सिद्धांत के साथ लिखी गई विधियां सामान्य उद्देश्य और अनुकूल होने की संभावना नहीं हैं। अत्यधिक विशिष्ट विधि के नाम पर। सामान्य तौर पर, जैसा कि ऊपर बताया गया है, आपका एप्लिकेशन कोड DRY और आपका यूनिट टेस्ट कोड DAMP होना चाहिए।

मुझे उम्मीद है कि इसे थोड़ा बेहतर तरीके से समझाने में मदद मिलेगी।

Answer 7

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

Answer 8

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

मैंने DRY vs DAMP के बारे में ब्लॉग किया है जिसमें कुछ उदाहरण शामिल हैं।

न तो दृष्टिकोण केवल आपका एकमात्र समाधान होना चाहिए, कभी-कभी डीएएमपी ओवरकिल होता है, अन्य बार बहुत अच्छा जोड़ होता है।

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