2015-03-12 6 views
5

मैं एक ऐसे अनुप्रयोग को विकसित कर रहा हूं जो Joda-Money पर भारी निर्भर करता है, और मेरे यूनिट परीक्षणों की पुष्टि करने वाले कई यूनिट परीक्षण हैं। मेरे लिए एक (स्वीकार्य रूप से मामूली) चिपकने वाला बिंदु यह है कि Money/BigMoney ऑब्जेक्ट्स के साथ परीक्षण करने के लिए किस प्रकार का प्रकार रहा है; विशेष रूप से, उपयोग करने के लिए CurrencyUnit क्या है।यूनिट परीक्षणों में किस मुद्रा का उपयोग करना है?

मैं इसे देखना रूप में, मैं कुछ विकल्प होते हैं:

  • बस USD

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

  • यह USD के गलत कड़ी मेहनत से codings को पकड़ने होगा, लेकिन अन्यथा तरह CAD

    एक और असली मुद्रा का प्रयोग करें, बस USD का उपयोग कर की तुलना में बेहतर नहीं है।

  • उपयोग एक समर्पित "fake" currency, अर्थात XTS

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

  • CurrencyUnit.registerCurrency()

    यह स्पष्ट रूप से काम करेगा के साथ अपने स्वयं के कस्टम मुद्रा रजिस्टर, लेकिन एक छोटे से अजीब देखने के रूप में वहाँ विकल्प हैं लगता है।

  • एक CurrencyUnit उदाहरण एक मजाक पुस्तकालय

    सुंदर ज्यादा एक कस्टम मुद्रा पंजीकरण के रूप में एक ही द्वारा बनाई का प्रयोग करें।

फिर, यह स्पष्ट रूप से एक छोटी सी समस्या नहीं है, लेकिन इस तरह के मामलों के लिए एक मानक अभ्यास हो, तो मैं उत्सुक हूँ, या विशेष रूप से इनमें से एक विकल्प पसंद करते हैं के लिए एक स्पष्ट कारण नहीं है यदि।

+0

यह मेरे लिए मामूली प्रतीत नहीं होता है। आप अपने पूरे यूनिट परीक्षणों पर इस निर्णय को फैलाने वाले हैं? यदि आप यह निर्णय केवल एक ही स्थान पर नहीं बना सकते हैं तो आप इसके साथ हमेशा के लिए अटक जाएंगे। – CandiedOrange

+0

@CandiedOrange सहमत हो गया, लेकिन मेरे पास अन्य प्रश्न हैं "आप इस पर अपना समय क्यों बर्बाद कर रहे हैं?!?!?!?!?" प्रतिक्रियाएं, इसलिए मेरी सभी जिज्ञासाओं को बुलाकर "नाबालिग" चिंताओं को रक्षा तंत्र का थोड़ा सा हिस्सा है। – dimo414

+2

हैटर्स नफरत करेंगे। पूछते रहो, उत्साहित रहो, और प्यार आपको मिल जाएगा। शांति। – CandiedOrange

उत्तर

2

यूएसडी का उपयोग करें (या, आम तौर पर, जो भी मुद्रा आपके आवेदन में सबसे अधिक उपयोग की जाती है)। मैं दो कारणों से यह कहना:

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

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

+1

धन्यवाद, कि तर्कसंगत छल्ले मेरे लिए काफी सच है। अगर मैं स्पष्ट रूप से मुद्रा-निर्भर है, तो मुझे यह कोड लिखना चाहिए, मुझे कई मुद्राओं में इसका परीक्षण करना चाहिए, मेरे लिए किनारे के मामलों को पेश करने के लिए परीक्षण ढांचे पर निर्भर नहीं है। – dimo414

संबंधित मुद्दे