उत्पादन और टेस्ट कोड कॉन्स्टेंट्स के बीच DRY

Question

मैं सामान्य रूप से डुप्लिकेशंस से बचने और DRY सिद्धांत का पालन करने का प्रयास करता हूं।

public class Feature { 
    final static String FEATURE_LABEL = "blah"; 

    public void doSomething() { ... } 
    ... 
} 

public class FeatureTest { 
    ... 
    @Test 
    public void doSomethingShouldMakeSomethingHappen() { 
     assertEquals(Feature.FEATURE_LABEL, 
      feature.getSomethingHappens().getLabel()); 
    } 

तो आवश्यकता है कि लेबल हो "blah" और किसी FEATURE_LABEL बदल जाता है "bleh", परीक्षण भी पारित करेंगे करने के लिए ही वह अब पूरा करती है: हालांकि, मैं इस तरह के मामले के बारे में सोच रहा हूँ आवश्यकता। क्या यह DRY का उल्लंघन करने के लिए एक वैध जगह है?

Answer 1

हां, यहां एक शाब्दिक उपयोग करें।

a question on literals से अपने आप का हवाला देते हुए:

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

यूनिट परीक्षण किसी भी अमूर्तता या पुनर्निर्देशन के बिना अपेक्षित मूल्यों का विवरण हैं। कल्पना करें कि आप परीक्षा पढ़ रहे हैं - आप सचमुच जानकारी के सामने चाहते हैं।

Answer 2

मैं इस पल के संदर्भ के साथ रहूंगा।

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

क्या इससे कोई मतलब है?

Answer 3

कुछ परीक्षण करने के लिए - कुछ भी - एक महत्वपूर्ण विचार यह है कि आपकी परीक्षा की स्थिति आप जो परीक्षण कर रहे हैं उससे स्वतंत्र हैं। अन्यथा, आपके परीक्षणों में एक एकल, भरोसेमंद अर्थ नहीं है; परीक्षा के तहत वस्तु हर बार जब वे किसी अन्य परीक्षा में बदल जाते हैं।

बहुत अच्छी बात नहीं है।

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

Answer 4

दूसरों को पहले से क्या कहा गया है यह व्यक्त करने का एक अलग तरीका: यदि परीक्षण कभी विफल नहीं हो सकता है, तो इसे रखने में कोई बात नहीं है। तो यह समझ में नहीं आता:

assertEquals(Feature.FEATURE_LABEL, Feature.FEATURE_LABEL); 

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

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

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

Answer 5

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

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