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




unit-testing (6)

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

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

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

डोमेन विशिष्ट भाषाओं के संबंध में यह DAMP द्वारा बनाया गया हो सकता है।

मैंने सुना है कि किसी ने कहा है कि यूनिट परीक्षण (उदाहरण के लिए nnnit, junit, xUnit) होना चाहिए

DAMP न करें

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

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


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

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

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

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

DRY (स्वयं को दोहराना न करें) कोड की orthogonality को बढ़ावा देता है।

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

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

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

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

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

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



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

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


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

मैंने डीआरवाई बनाम डीएएमपी के बारे में ब्लॉग किया है जिसमें कुछ उदाहरण शामिल हैं।

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

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


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

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

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

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

उदाहरण: testWhenIAddOneAndOneIShouldGetTwo() { .... }

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

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

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

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





unit-testing