नकली वस्तुओं को बांधने के लिए एक परीक्षण विधि के अंदर स्थानीय रूप से बाध्यकारी निंजा

Question

मुझे निम्नलिखित समस्या है, मैं अपने यूनिट परीक्षणों में निनजेक्ट का उपयोग करना चाहता हूं। इस बारे में मेरे विचार इस तरह थे:

1) एक मॉड्यूल के अंदर एक वैश्विक बाध्यकारी स्कीमा निर्धारित मेरी नकली वस्तुओं है कि मैं परीक्षण के अंदर का उपयोग बाध्य करने के लिए

2) यह बाँध एक नकली वस्तु का उपयोग करते समय के अंदर स्थानीय स्तर पर परीक्षण

मुझे बाध्यकारी कॉन्फ़िगरेशन को स्थानीय रूप से ओवरराइड करने का कोई तरीका नहीं मिला, मेरा विचार है कि मैं स्थानीय रूप से अपेक्षाओं के साथ एक नकली वस्तु बना देता हूं और मैं कर्नेल चाहता हूं।()() विधि को उस ऑब्जेक्ट को वापस करने के लिए जिसमें सभी बाध्यकारी हैं यह जगह छोड़कर कि प्रत्येक परीक्षण एक स्थानीय मॉक ऑब्जेक्ट को अपेक्षाओं के साथ एक परीक्षण के अंदर जोड़ता है, यह मुझे पठनीय और रखरखाव करने के लिए लगता है, क्योंकि मैं प्रति परीक्षण 1 बाध्यकारी ओवरराइड करता हूं, ऑब्जेक्ट्स ar ई mocks ताकि उन्हें मॉड्यूल के अंदर कॉन्फ़िगर नहीं किया जा सके क्योंकि परीक्षण संदर्भ अज्ञात है

मैं इसे कैसे पूरा कर सकता हूं, मैं C# और nunit का उपयोग कर रहा हूं। यदि मेरी पद्धति गलत है तो मैं सही सुनना चाहूंगा।

Answer 1

आपको अपने आईओसी कंटेनर का उपयोग उस ऑब्जेक्ट को बनाने के लिए नहीं करना चाहिए जिससे आप अपने यूनिट परीक्षणों में परीक्षण करना चाहते हैं। इसके बजाय इसे new का उपयोग करके मैन्युअल रूप से बनाएं और प्रत्येक कन्स्ट्रक्टर तर्क के लिए एक नकली/स्टब ऑब्जेक्ट पास करें।

Answer 2

मुझे एक ही समस्या है और मैं समझता हूं कि यह करने का अच्छा तरीका नहीं है लेकिन मेरी तरफ, मैं एकीकरण परीक्षण करता हूं; इकाई परीक्षण नहीं।

Kernel.Rebind<TypeToBind>().ToConstant(Mock.Object); 

कहाँ कर्नेल उद्देश्य यह है कि आप बाध्यकारी बनाने के लिए इस्तेमाल होता है:

यहाँ मेरी समाधान है। TypeToBind वह प्रकार है जिसे आप निर्भरता इंजेक्ट करना चाहते हैं। मॉक.ऑब्जेक्ट वह ऑब्जेक्ट है जिसे आपने पहले सेटअप किया था।

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

Answer 3

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

एटनीट जैसे ढांचे भी हैं जहां आप ऑब्जेक्ट का परीक्षण करने के लिए डी फ्रेमवर्क का उपयोग कर रहे हैं और नए कीवर्ड का बिल्कुल उपयोग नहीं करते हैं। (दुर्भाग्य से, मुझे उस ढांचे का बंदरगाह अभी तक सी # भूमि में नहीं दिख रहा है :()

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