परीक्षण के बाहर नकली वस्तुओं का उपयोग, बुरा अभ्यास?

Question

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

कट परिदृश्यों, लॉगिंग चिंताओं, डेवलपर प्रयोज्य, विन्यास, आदि का समर्थन करने के ... मैं एक दृष्टिकोण जो काफी हद तक जेनरिक और अभिव्यक्ति के पेड़ का उपयोग करता है का उपयोग कर प्रयोग किया गया है। अंतिम परिणाम इस प्रकार है:

Messenger<NetflixApi>.SendCustom(netflix => netflix.RecommendMovie("my message")); 

कुल मिलाकर मैं अंतिम परिणाम के साथ खुश हूँ, लेकिन लगता है कि मैं एक गलती की है, या परीक्षण और डिस्कनेक्ट परिदृश्यों के संबंध में एक डिजाइन प्रिंसिपल किसी ऐसे स्थान पर अनदेखी की।

परीक्षण के दौरान, चाहे स्वचालित, इकाई या मानव आधारित, मैंने एक ऑब्जेक्ट फैक्ट्री लागू की है जो प्रारंभ में "लाइव मोड" में सही कार्रवाई करने के लिए DI का उपयोग करती है और एक प्रकार का बाँझ मैसेंजर प्रदान करने के लिए मैक्स का उपयोग करती है जो ' एक परीक्षण मोड में जब भी कुछ भी नहीं करते हैं।

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

मेरी मुख्य चिंता यह है कि मैं उन सभी अलग-अलग सेवाओं को जोड़ूंगा जिनसे मैं कनेक्ट होने की उम्मीद करता हूं, मैं विशिष्ट HTTP कार्यान्वयन को प्रतिस्थापित करने के लिए बहुत सारे दानेदार काम करने के लिए समाप्त होता हूं और यदि मैंने स्टब दृष्टिकोण का उपयोग किया तो मेरे पास 3 कक्षाएं होंगी इन सेवाओं में से प्रत्येक (IService, ConcreteService, StubService) और किसी नई विधि को लागू करने या किसी भी चीज़ को बदलने पर बनाए रखने से वास्तविक पिटा होगा।

वर्तमान कार्यान्वयन में मैं "कुछ बाँझ मोड" प्राप्त करने के लिए मोक्स का उपयोग कर रहा हूं, बिना किसी निश्चित परीक्षण प्रिंसिपल के अनुरूप कुछ अतिरिक्त लागू किए बिना।

सवाल मैं कुछ याद आ रही है है? क्या मैंने मोक्स का उपयोग करके एक डिजाइन प्रिंसिपल का अधिक उपयोग किया ... सुविधाजनक तरीका?

किसी को भी कैसे हुप्स का एक बहुत माध्यम से कूद के बिना कई अलग अलग बाहर सेवाओं के बाहर एक बाँझ मोड पाने के लिए पर कोई सलाह दे सकते हैं?

क्या यह प्रश्न समझ में आता है?

सभी उत्तरों के लिए धन्यवाद।

# 1 संपादित करें:

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

मैंने सभी को वोट दिया क्योंकि इस समस्या के बहुत से समाधान हैं और मैं प्रत्येक की खोज करूँगा।

कृपया नहीं लगता कि इस सवाल का जवाब अभी तक कर दिया गया है, मैं के रूप में ज्यादा सलाह की सराहना करेंगे, के रूप में मैं प्राप्त कर सकते हैं।

Answer 1

नल ऑब्जेक्ट नामक एक डिज़ाइन पैटर्न है। एक शून्य वस्तु एक वस्तु है जो एक इंटरफ़ेस लागू करती है, इसलिए इसका उपयोग आपके जैसे परिदृश्य में किया जा सकता है।

नल ऑब्जेक्ट के बारे में महत्वपूर्ण बात यह है कि उन जगहों पर शून्य न लौएं जहां सिस्टम को तोड़ सकता है।

नल ऑब्जेक्ट का उद्देश्य किसी मॉक की तरह, किसी चीज़ का शून्य और सरल कार्यान्वयन होना है, लेकिन उत्पादन वातावरण में उपयोग किया जाना है। मुझे आशा है कि आप प्रॉक्सी पैटर्न पर एक नजर है करने के लिए चाहते हो सकता है इस तरह आप

Answer 2

मैं आप अपने प्रश्न को स्पष्ट करने की आवश्यकता हो सकती है लगता है। मैं इस बात के बारे में अस्पष्ट नहीं हूं कि परीक्षण के परीक्षण में परीक्षण युगल का उपयोग करने के बारे में आप बात कर रहे हैं या उम्मीदों के परीक्षण के बिना (इसलिए उन्हें आवश्यक इंटरफेस को पूरा करने के लिए नकली के रूप में उपयोग करना) या क्या आप सेवाओं के लिए भरने के लिए उत्पादन परिदृश्य में मोक्स का उपयोग करने के बारे में बात कर रहे हैं जो उपलब्ध नहीं हैं (आपका डिस्कनेक्ट परिदृश्य)।

यदि आप परीक्षण स्थितियों में बात कर रहे हैं: मोक्स परीक्षण युगल हैं। नकली या स्टब्स के विरोध में नकली का उपयोग करके परीक्षण में कुछ भी गलत नहीं है। यदि आपको किसी विशिष्ट परीक्षण में सेवा का उपयोग करने की आवश्यकता नहीं है और यह केवल एक दिया गया इंटरफ़ेस प्रदान करने के लिए है कि परीक्षण के तहत ऑब्जेक्ट पर निर्भरता है तो यह ठीक है। वह किसी भी परीक्षण प्रिंसिपल को तोड़ नहीं रहा है।

अच्छी मॉकिंग लाइब्रेरी मोक्स, स्टब्स और नकली के बीच की रेखाओं को धुंधला कर रही हैं।

मार्टिन फाउलर से विभिन्न प्रकार के परीक्षण युगल पर कुछ जानकारी देखें। Mocks Aren't Stubs, TestDoubles।

मुझे वास्तव में पसंद है कि moq विशिष्ट व्यवहार प्राप्त करने के लिए हुप्स के माध्यम से कूदने की आवश्यकता के बिना डमी, नकली, स्टब और नकली वस्तुओं के बीच निरंतरता की अनुमति देता है। Check it out।

यदि आप उत्पादन के उपयोग के लिए अपने डिस्कनेक्ट किए गए परिदृश्य में मोक्स का उपयोग करने के बारे में बात कर रहे हैं ... मुझे चिंता होगी। एक फर्जी आपके द्वारा किए गए किसी भी कॉल के लिए शून्य ऑब्जेक्ट्स या डिफ़ॉल्ट मान वापस करने जा रहा है। यह इन सेवाओं का उपभोग करने वाले सभी कोडों में जटिलता को रिसाव करेगा (उन्हें शून्य वापसी मूल्यों और खाली सरणी के लिए जांच को संभालने की आवश्यकता होगी ...)। मुझे लगता है कि यह आपके डिस्कनेक्ट/बाँझ परिदृश्य को संभालने के लिए और अधिक समझ में आएगा कि निर्भरता स्वयं उनके नकली कार्यान्वयन को स्वीकार करने के बजाय अनुपलब्ध हैं और जैसे कि सब कुछ काम कर रहा है।

Answer 3

यह मेरे लिए लग रहा है मदद कर सकता है

class Logger{ 
private static ILogger _Logger; 

static Logger(){ 
    //DI injection here 
    _Logger = new NullLogger(); //or 
    _Logger = new TraceLogger(); 
} 
} 

interface ILogger{ 
void Log(string Message); 
} 

internal class TraceLogger:ILooger{ 
public void Log(string Message){ 
    //Code here 
} 
} 

internal class NullLogger{ 
public void Log(string Message){ 
    //Don't don anything, in purporse 
} 
} 

:

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