NMock बनाम VS 2011 फेक फ्रेमवर्क जैसे मॉक फ्रेमवर्क के मतभेदों पर थोड़ा भ्रमित। MSDN के माध्यम से जा रहा है, जो मैं समझता हूं कि फेक आपको राइनोमॉक या NMock की तरह अपनी निर्भरता का मजाक उड़ाने की अनुमति देता है, हालांकि दृष्टिकोण अलग है, फेक इस कार्यक्षमता को प्राप्त करने के लिए कोड उत्पन्न करता है लेकिन मोक्स फ्रेमवर्क नहीं करता है। तो क्या मेरी समझ सही है? क्या नकली सिर्फ एक और नकली ढांचा है
जवाबों:
आपका प्रश्न इस बारे में था कि MS Fakes फ्रेमवर्क NMock से किस तरह अलग है और ऐसा लगता है कि अन्य उत्तरों से कुछ हल हो गए हैं, लेकिन यहाँ कुछ और जानकारी दी गई है कि वे कैसे हैं और वे कैसे भिन्न हैं। NMock भी RhinoMocks और Moq के समान है, इसलिए मैं उन्हें NMock के साथ समूहीकृत कर रहा हूं।
NMock / RhinoMocks / Moq और MS Fakes फ्रेमवर्क के बीच 3 मुख्य अंतर हैं
एमएस फेक फ्रेमवर्क जेनेरिक प्रकारों के बजाय विजुअल स्टूडियो के पूर्व संस्करणों में एक्सेसर्स की तरह उत्पन्न कोड का उपयोग करता है। जब आप एक निर्भरता के लिए फ़ेक फ्रेमवर्क का उपयोग करना चाहते हैं, तो आप असेंबली को जोड़ते हैं जिसमें परीक्षण प्रोजेक्ट के संदर्भों पर निर्भरता होती है और फिर परीक्षण डबल्स (स्टब्स या शम्स) उत्पन्न करने के लिए उस पर राइट-क्लिक करें। फिर जब आप परीक्षण कर रहे हैं, तो आप वास्तव में इन उत्पन्न वर्गों का उपयोग कर रहे हैं। NMock एक ही चीज़ (यानी IStudentRepository studentRepository = mocks.NewMock<IStudentRepository>()) को पूरा करने के लिए जेनेरिक का उपयोग करता है । मेरी राय में, एमएस फेक फ्रेमवर्क दृष्टिकोण कोड नेविगेशन को बाधित करता है और परीक्षणों के भीतर से रिफैक्टिंग करता है क्योंकि आप वास्तव में एक उत्पन्न वर्ग के खिलाफ काम कर रहे हैं, न कि आपका वास्तविक इंटरफ़ेस।
एमएस ढांचे की आपूर्ति स्टब्स और मोल (शिम्स), जबकि NMock, RhinoMocks, और Moq सभी स्टब्स और प्रदान नकली mocks । मैं वास्तव में एमएसीएस के निर्णय को नहीं समझता हूं कि इसमें मॉक शामिल नहीं है और मैं नीचे वर्णित कारणों से व्यक्तिगत रूप से मोल्स का प्रशंसक नहीं हूं।
एमएस फेक ढांचे के साथ, आप उन तरीकों के वैकल्पिक कार्यान्वयन की आपूर्ति करते हैं जिन्हें आप स्टब करना चाहते हैं। इन वैकल्पिक कार्यान्वयनों के भीतर, आप रिटर्न मान निर्दिष्ट कर सकते हैं और इस बारे में जानकारी ट्रैक कर सकते हैं कि कैसे या अगर विधि को बुलाया गया था। NMock, RhinoMocks और Moq के साथ, आप एक मॉक ऑब्जेक्ट जेनरेट करते हैं और फिर स्टैब्ड रिटर्न वैल्यूज़ को निर्दिष्ट करने के लिए या इंटरैक्शन को ट्रैक करने के लिए उस ऑब्जेक्ट का उपयोग करते हैं (चाहे और कैसे तरीकों को बुलाया गया था)। मुझे लगता है कि एमएस फेक अधिक जटिल और कम अभिव्यंजक दृष्टिकोण करते हैं।
फ्रेमवर्क क्या प्रदान करते हैं, इसके अंतर को स्पष्ट करने के लिए: NMock, RhinoMocks और Moq सभी दो प्रकार के टेस्ट डबल्स (स्टब्स और मॉक) प्रदान करते हैं। नकली फ्रेम स्टब्स और मोल्स प्रदान करता है (वे उन्हें शिम कहते हैं), और दुर्भाग्य से मोक्स शामिल नहीं हैं। NMock और MS Fakes के बीच अंतर और समानता को समझने के लिए, यह समझना उपयोगी है कि ये विभिन्न प्रकार के परीक्षण युगल क्या हैं:
स्टब्स: स्टब्स का उपयोग तब किया जाता है जब आपको तरीकों या गुणों के लिए एक मान प्रदान करने की आवश्यकता होती है जो परीक्षण के तहत विधि द्वारा आपके परीक्षण डबल्स के बारे में पूछा जाएगा। उदाहरण के लिए, जब परीक्षण के तहत मेरा तरीका IStudentRepository परीक्षण के DoStudentExist () विधि को दोहराता है, तो मैं चाहता हूं कि यह सच हो।
NMock और MS फेक में स्टब्स का विचार एक समान है, लेकिन NMock के साथ आप कुछ इस तरह करेंगे:
Stub.On(mockStudentRepository).Method("DoesStudentExist").Will(Return.Value(true));
और MSFakes के साथ आप इस तरह से काम करेंगे:
IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository() // Generated by Fakes.
{
DoesStudentExistInt32 = (studentId) => { return new Student(); }
};
MS Fakes उदाहरण में सूचना आप DoStudentExist पद्धति के लिए एक पूरी तरह से नया कार्यान्वयन बनाते हैं (ध्यान दें कि इसे DoStudentExistInt32 कहा जाता है क्योंकि नकली फ्रेम पैरामीटर डेटा प्रकारों को विधि नामों में जोड़ देता है जब यह स्टब ऑब्जेक्ट्स उत्पन्न करता है, मुझे लगता है कि यह अस्पष्टता को स्पष्ट करता है जाँच)। ईमानदार होने के लिए NMock कार्यान्वयन भी मुझे परेशान करता है क्योंकि यह विधि नाम की पहचान करने के लिए एक स्ट्रिंग का उपयोग करता है। (मुझे माफ़ कर दो अगर मैंने गलत समझा कि NMock का उपयोग कैसे किया जाता है।) यह दृष्टिकोण वास्तव में रिफैक्टिंग को रोकता है और मैं इस कारण से NMock पर RhinoMocks या Moq की अत्यधिक अनुशंसा करता हूँ।
मोक्स: मोक्स का उपयोग परीक्षण और इसकी निर्भरता के तहत आपकी विधि के बीच बातचीत को सत्यापित करने के लिए किया जाता है। NMock के साथ, आप इस तरह की अपेक्षाओं को स्थापित करके ऐसा करते हैं:
Expect.Once.On(mockStudentRepository).Method("Find").With(123);
यह एक और कारण है कि मैं NMock पर राइनोमॉक्स और Moq को क्यों पसंद करूंगा, NMock पुरानी उम्मीद की शैली का उपयोग करता है जबकि RhinoMocks और Moq दोनों ही अरेंज / एक्ट / एस्टर के दृष्टिकोण का समर्थन करते हैं जहां आप इस तरह के परीक्षण के अंत में मुखर होने के रूप में अपेक्षित इंटरैक्शन निर्दिष्ट करते हैं। :
stubStudentRepository.AssertWasCalled( x => x.Find(123));
फिर, ध्यान दें कि RhinoMocks विधि की पहचान करने के लिए एक स्ट्रिंग के बजाय एक लैम्ब्डा का उपयोग करता है। एमएस फेक फ्रेमवर्क मोक्स प्रदान नहीं करता है। इसका मतलब यह है कि आपके स्टब आउट कार्यान्वयन में (ऊपर स्टब्स का विवरण देखें) आपको चर सेट करने होंगे जिन्हें आपने बाद में सत्यापित किया था कि वे सही ढंग से सेट किए गए हैं। यह कुछ इस तरह दिखेगा:
bool wasFindCalled = false;
IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository()
{
DoesStudentExistInt32 = (studentId) =>
{
wasFindCalled = true;
return new Student();
}
};
classUnderTest.MethodUnderTest();
Assert.IsTrue(wasFindCalled);
मुझे लगता है कि यह दृष्टिकोण थोड़ा जटिल है क्योंकि आपको स्टब में कॉल को ट्रैक करना होगा और फिर बाद में परीक्षण में जोर देना होगा। मैं NMock, और विशेष रूप से RhinoMocks, और अधिक अर्थपूर्ण होने के लिए उदाहरण ढूंढता हूं।
मोल्स (शिम्स): फ्रैंक होने के लिए, मुझे मोल्स पसंद नहीं हैं, क्योंकि उनके दुरुपयोग की संभावना है। यूनिट टेस्टिंग (और विशेष रूप से टीडीडी) के बारे में मुझे जो चीजें पसंद हैं उनमें से एक यह है कि आपके कोड का परीक्षण आपको यह समझने में मदद करता है कि आपके पास कहां खराब कोड है। ऐसा इसलिए है क्योंकि खराब लिखित कोड का परीक्षण करना मुश्किल है। मोल्स का उपयोग करते समय यह सच नहीं है क्योंकि मोल्स वास्तव में आपको उन निर्भरता के खिलाफ परीक्षण करने की अनुमति देने के लिए डिज़ाइन किए गए हैं जो इंजेक्शन नहीं हैं या निजी तरीकों का परीक्षण करने के लिए हैं। वे स्टब्स के समान काम करते हैं, सिवाय इसके कि आप इस तरह से शिम्सकोटेक्स्ट का उपयोग करते हैं:
using (ShimsContext.Create())
{
System.Fakes.ShimDateTime.NowGet = () => { return new DateTime(fixedYear, 1, 1); };
}
शिमर्स के साथ मेरी चिंता यह है कि लोग उन्हें "यूनिट टेस्ट के लिए एक आसान तरीका" के रूप में देखना शुरू कर देंगे क्योंकि यह आपको उस तरह से कोड लिखने के लिए मजबूर नहीं करता है जो आपको करना चाहिए। इस अवधारणा पर एक और पूर्ण लिखने के लिए मेरा यह पोस्ट देखें:
फ़ेक फ्रेमवर्क से संबंधित कुछ चिंताओं के बारे में अधिक जानकारी के लिए इन पदों पर एक नज़र डालें:
यदि आप यहां राइनोमॉक्स सीखने में रुचि रखते हैं, तो प्लुरलइट प्रशिक्षण वीडियो (पूर्ण प्रकटीकरण - मैंने यह पाठ्यक्रम लिखा है और विचारों के लिए रॉयल्टी का भुगतान किया है, लेकिन मुझे लगता है कि यह इस चर्चा पर लागू होता है, इसलिए मैं इसे यहां शामिल करता हूं):
आप सही हैं, लेकिन कहानी में कुछ और भी है। इस उत्तर से दूर करने के लिए सबसे महत्वपूर्ण चीजें हैं:
आपकी वास्तुकला को फ़ेक और मॉक के क्रैच पर निर्भर होने के बजाय, स्टब्स और निर्भरता इंजेक्शन का उचित उपयोग करना चाहिए
नकली और नकली परीक्षण कोड के लिए उपयोगी हैं जिन्हें आप बदल सकते हैं या नहीं, जैसे:
शिम्स (विकास के दौरान "मोल्स" के रूप में जाना जाता है), वास्तव में एक नकली रूपरेखा है जो अलग-अलग कॉल के माध्यम से संचालित होता है। श्रमसाध्य निर्माण के बजाय एक नकली (हाँ, यहां तक कि Moq का उपयोग अपेक्षाकृत दर्दनाक है!), शिम बस उत्पादन कोड ऑब्जेक्ट का उपयोग पहले से ही कर रहे हैं। शिम केवल उत्पादन लक्ष्य से परीक्षण प्रतिनिधि को कॉल को फिर से रूट करता है।
लक्ष्य परियोजना में इंटरफेस से स्टब्स उत्पन्न होते हैं। स्टब ऑब्जेक्ट बस यही है - इंटरफ़ेस का एक कार्यान्वयन। स्टब प्रकार का उपयोग करने का लाभ यह है कि आप कई बार एक बार उपयोग किए जाने वाले स्टब्स के साथ अपने परीक्षण प्रोजेक्ट को बंद किए बिना एक स्टब उत्पन्न कर सकते हैं, न कि उन्हें बनाने वाले समय बर्बाद करने का उल्लेख करने के लिए। बेशक, आपको अभी भी कई परीक्षणों के उपयोग के लिए, कंक्रीट स्टब्स बनाने चाहिए।
कुशलता से फेक (शिम्स, मोक्स और स्टब प्रकार) को लागू करने में थोड़ा समय लगता है, लेकिन यह प्रयास के लायक है। मैंने व्यक्तिगत रूप से विकास के समय को शम्स / मोल, मोक्स और स्टब प्रकार के उपयोग के माध्यम से बचाया है। मुझे आशा है कि आपके पास तकनीक के साथ उतना ही मज़ा होगा जितना मेरे पास है!
जैसा कि मैं इसे समझता हूं, विजुअल स्टूडियो टीम .NET के लिए उपलब्ध विभिन्न मॉक लाइब्रेरी के साथ प्रतिस्पर्धा करने से बचना चाहती थी। एमएस अक्सर इस तरह के कठिन फैसलों का सामना करते हैं। यदि वे कुछ कार्यक्षमता प्रदान नहीं करते हैं तो उन्हें नुकसान पहुंचता है ("क्यों एमएस हमें एक नकली पुस्तकालय प्रदान नहीं करता है? नकली ऐसी आम आवश्यकता है?") और शापित अगर वे करते हैं ("तो Microsoft इतनी आक्रामक तरीके से काम क्यों कर रहा है और इसे चला रहा है" बाजार से बाहर प्राकृतिक समर्थक? ") बहुत बार, लेकिन हमेशा नहीं, वे उपलब्ध और अच्छी तरह से प्राप्त प्रौद्योगिकियों के लिए अपना स्वयं का विकल्प प्रदान करने से पीछे हटने का फैसला करते हैं। यहां ऐसा ही प्रतीत होता है।
फेक की शिम फीचर वास्तव में उपयोगी है। यकीन है, खतरे हैं। यह सुनिश्चित करने के लिए कुछ अनुशासन लेता है कि आप केवल इसका उपयोग करें जहां आवश्यक हो। हालांकि, यह एक बड़ा अंतर भरता है। मेरी मुख्य शिकायत यह है कि यह केवल वीएस 2012 के अंतिम संस्करण के साथ दिया गया है और इसलिए यह केवल .NET विकास समुदाय के एक उप-वर्ग के लिए उपलब्ध होगा। अफ़सोस की बात है।
नकली में "नकली" ऑब्जेक्ट के दो अलग-अलग प्रकार शामिल हैं। पहला, जिसे "स्टब" कहा जाता है, अनिवार्य रूप से एक ऑटो-जनित डमी है जिसका डिफ़ॉल्ट व्यवहार (और आमतौर पर) इसे एक अधिक दिलचस्प नकली बनाने के लिए ओवरराइड किया जाएगा। हालाँकि, इसमें कुछ ऐसी विशेषताओं का अभाव है, जो वर्तमान में उपलब्ध अधिकांश मॉकिंग फ्रेमवर्क प्रदान करते हैं। उदाहरण के लिए, यदि आप जांचना चाहते हैं कि स्टब उदाहरण पर एक विधि लागू की गई थी, तो आपको इसके लिए तर्क जोड़ने की आवश्यकता होगी। असल में, यदि आप अपने स्वयं के मोक्स को मैन्युअल रूप से लिख रहे हैं, तो स्टब्स शायद एक सुधार की तरह प्रतीत होंगे। हालाँकि, यदि आप पहले से ही अधिक पूर्ण विशेषताओं वाले मॉकिंग फ्रेमवर्क का उपयोग कर रहे हैं, तो आपको ऐसा लग सकता है कि फेक स्टब्स से कुछ महत्वपूर्ण टुकड़े गायब हैं।
फेक द्वारा पेश की गई वस्तु की एक अन्य श्रेणी, जिसे "शिम" कहा जाता है, निर्भरता के व्यवहार को बदलने के लिए एक तंत्र को उजागर करती है जो मॉक के माध्यम से मानक प्रतिस्थापन के लिए पर्याप्त रूप से डिकॉउंड नहीं किया गया है। AFAIK, टाइपमॉक केवल एक प्रमुख नकली रूपरेखा है जो वर्तमान में इस प्रकार की कार्यक्षमता प्रदान करता है।
BTW, यदि आपने पहले मोल्स को आज़माया है, तो फ़ेक अनिवार्य रूप से एक ही चीज़ है, आखिरकार माइक्रोसॉफ्ट रिसर्च और वास्तविक उत्पाद में अपना रास्ता बना रहा है।
नकली (शिम + स्टब) वस्तुओं के बारे में, यह ऊपर अच्छी तरह से परिभाषित किया गया है, हालांकि मुझे लगता है कि अंतिम टिप्पणी में अंतिम पैराग्राफ पूरी स्थिति को बहुत अच्छी तरह से सारांशित करता है।
हालांकि बहुत से लोग तर्क देंगे कि कुछ इकाई परीक्षण मामलों में नकली (शिम + स्टब) वस्तुएं अच्छी संपत्ति हैं, नकारात्मक पक्ष यह है कि कोई फर्क नहीं पड़ता कि आप विजुअल स्टूडियो 2012 या विज़ुअल स्टूडियो 2013 का उपयोग कर रहे हैं, ये विकल्प केवल उपलब्ध हैं प्रीमियम या अंतिम संस्करणों के साथ। IOW, इसका मतलब है कि आप किसी भी प्रो संस्करण पर उन फेक (शिम + स्टब) को चलाने के लिए नहीं होंगे।
आप शायद प्रो संस्करणों पर फेक (शिम + स्टब) मेनू विकल्प देख सकते हैं, लेकिन खबरदार, कुछ बहुत मजबूत संभावनाएं हैं कि आप पूरी तरह से कुछ भी नहीं खत्म कर देंगे ... यह आपको कोई संकलन त्रुटि उत्पन्न नहीं करेगा जो आपको बताएगा कि कुछ महत्वपूर्ण है गायब है, विकल्प अभी नहीं हैं, इसलिए अपना समय बर्बाद न करें ...
देव टीम में विचार करने के लिए यह एक महत्वपूर्ण कारक है, खासकर अगर कोई एक ही अंतिम संस्करण का उपयोग कर रहा है, जबकि बाकी सभी प्रो संस्करण का उपयोग करते हैं ... दूसरी ओर Moq को आसानी से Nuget के माध्यम से स्थापित किया जा सकता है कोई फर्क नहीं पड़ता कि आप किस विज़ुअल स्टूडियो संस्करण का उपयोग करते हैं। मुझे Moq का उपयोग करने में कोई समस्या नहीं थी, किसी भी उपकरण के साथ कुंजी यह जानना है कि वे क्या उपयोग कर रहे हैं और उन्हें ठीक से कैसे उपयोग करें;)