2012-03-13 7 views
84

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

उत्तर

12

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

नकली द्वारा पेश की गई अन्य श्रेणी की वस्तु, जिसे "शिम" कहा जाता है, निर्भरता के व्यवहार को बदलने के लिए एक तंत्र का खुलासा करता है जो मैक्स के माध्यम से मानक प्रतिस्थापन के लिए पर्याप्त रूप से decoupled (या नहीं किया जा सकता)। AFAIK, TypeMock प्रमुख मॉकिंग फ्रेमवर्कों में से एकमात्र ऐसा है जो वर्तमान में इस प्रकार की कार्यक्षमता प्रदान करता है।

बीटीडब्ल्यू, यदि आपने पहले मोल्स की कोशिश की है, तो नकली अनिवार्य रूप से वही बात है, अंततः माइक्रोसॉफ्ट रिसर्च से बाहर निकलने और वास्तविक उत्पाद में अपना रास्ता बना रही है।

+1

अपडेट: मोल्स को अब एमएस फॉक्स में एकीकृत किया गया है। "विजुअल स्टूडियो 2012 में फॉक्स फ्रेमवर्क अगली पीढ़ी के मोल्स एंड स्टब्स है। नकली मोल्स से अलग है, हालांकि, मोल्स से फेक्स तक जाने के लिए आपके कोड में कुछ संशोधन की आवश्यकता होगी। मोल्स फ्रेमवर्क को विजुअल स्टूडियो 2012 में समर्थित नहीं किया जाएगा । " स्रोत: http://research.microsoft.com/en-us/projects/moles/ – Sire

21

आप सही हैं, लेकिन कहानी के लिए और भी कुछ है। सबसे महत्वपूर्ण बातें इस जवाब से दूर ले करने के लिए कर रहे हैं:

  1. आपका वास्तुकला, बल्कि नकली बैसाखी पर भरोसा करने की बजाय स्टब्स और निर्भरता इंजेक्शन के समुचित उपयोग करना चाहिए और

  2. नकली का मजाक उड़ाता है

    • विरासत कोड है कि हम नहीं कर सकता: और mocks जैसे, परीक्षण कोड आप या नहीं बदल नहीं सकते चाहिए लिए उपयोगी होते हैं ई (या कुशल उपयोग) स्टब्स की
    • 3 पार्टी एपीआई
    • संसाधन है जिसके लिए आप कोई स्रोत कोड है

shims, (दौरान के रूप में "मोल्स", जाना जाता है विकास) वास्तव में एक मॉकिंग फ्रेमवर्क है जो कॉल को रोकने के तरीके से संचालित होता है। दर्दनाक रूप से एक मॉक बनाने के बजाय (हाँ, यहां तक ​​कि मोक का उपयोग करना अपेक्षाकृत दर्दनाक है!), शिम्स केवल पहले से ही उत्पादन कोड ऑब्जेक्ट का उपयोग करते हैं। शिम्स केवल उत्पादन लक्ष्य से परीक्षण प्रतिनिधि को कॉल को फिर से रूट करते हैं।

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

कुशलता से लागू नकली (शिम्स, मोक्स और स्टब प्रकार) को थोड़ा सा उपयोग करने में मदद मिलती है, लेकिन यह प्रयास के लायक है। मैंने व्यक्तिगत रूप से शिम्स/मोल, मोक्स और स्टब प्रकारों के उपयोग के माध्यम से विकास के समय के हफ्तों को बचाया है। मुझे आशा है कि आपके पास तकनीक के साथ उतना मज़ा आएगा जितना मेरे पास है!

+11

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

+1

लेकिन शिम्स (मोल्स), यानी तृतीय पक्ष कोड, सिस्टम/एसडीके एपीआई के उपयोग के लिए अच्छा औचित्य जोड़ता है। यह सिर्फ तब नहीं है जब आप अपने घर के समाधान के साथ काम कर रहे हों। तो मैं आपको यह भी बता दूंगा कि :-) –

+2

@ माइक और जिम .. मैंने इस उत्तर में उपयोग की जाने वाली शब्दावली को सही करने का प्रयास किया। अगर हम इसे बेहतर बना सकते हैं तो कृपया मुझे बताएं। धन्यवाद। – Snesh

167

आपका प्रश्न यह था कि एमएस फॉक्स फ्रेमवर्क एनएमॉक से अलग कैसे है और ऐसा लगता है कि अन्य उत्तरों ने इसका कुछ हल किया है, लेकिन यहां कुछ और जानकारी है कि वे समान कैसे हैं और वे अलग कैसे हैं। एनएमॉक राइनोमोक्स और मोक के समान भी है, इसलिए मैं उन्हें एनएमॉक के साथ समूहित कर रहा हूं।

इसमें 3 प्रमुख मतभेद मैं सही NMock/RhinoMocks/Moq और एमएस नकली फ्रेमवर्क के बीच विदा कर रहे हैं: बजाय दृश्य स्टूडियो के पूर्व संस्करण में

  • एमएस नकली ढांचे कोड उत्पन्न का उपयोग करता है, बहुत पहुंचकर्ता की तरह सामान्य प्रकार के। जब आप निर्भरता के लिए नकली ढांचे का उपयोग करना चाहते हैं, तो आप उस असेंबली को जोड़ते हैं जिसमें परीक्षण प्रोजेक्ट के संदर्भों पर निर्भरता होती है और फिर परीक्षण युगल (स्टब्स या शिम्स) उत्पन्न करने के लिए उस पर राइट-क्लिक करें। फिर जब आप परीक्षण कर रहे हों, तो आप वास्तव में इन जेनरेट किए गए वर्गों का उपयोग कर रहे हैं। NMock एक ही चीज़ को पूरा करने के लिए जेनेरिक का उपयोग करता है (यानी IStudentRepository studentRepository = mocks.NewMock<IStudentRepository>())। मेरी राय में, एमएस फ्लेक्स फ्रेमवर्क दृष्टिकोण कोड नेविगेशन को रोकता है और परीक्षणों के भीतर से रिफैक्टरिंग करता है क्योंकि आप वास्तव में जेनरेट क्लास के खिलाफ काम कर रहे हैं, न कि आपके असली इंटरफेस।

  • एमएस नकली ढांचे की आपूर्ति स्टब्स और मोल (शिम्स), जबकि NMock, RhinoMocks, और Moq सभी स्टब्स प्रदान करते हैं और का मजाक उड़ाता है। मैं वास्तव में एमओएस के मॉक्स को शामिल करने का निर्णय नहीं समझता हूं और मैं व्यक्तिगत रूप से नीचे वर्णित कारणों के लिए मोल का प्रशंसक नहीं हूं।

  • एमएस नकली ढांचे के साथ, आप उन विधियों के वैकल्पिक कार्यान्वयन की आपूर्ति करते हैं जिन्हें आप स्टब करना चाहते हैं। इन वैकल्पिक कार्यान्वयन के भीतर, आप रिटर्न वैल्यू निर्दिष्ट कर सकते हैं और विधि को कैसे या कैसे कहा जाता है, इस बारे में जानकारी ट्रैक कर सकते हैं। एनमोक, राइनोमोक्स और मोक के साथ, आप एक नकली वस्तु उत्पन्न करते हैं और फिर उस वस्तु का उपयोग स्टब किए गए रिटर्न मान निर्दिष्ट करने या इंटरैक्शन ट्रैक करने के लिए करते हैं (चाहे और कैसे विधियों को बुलाया गया हो)। मुझे लगता है कि एमएस नकली अधिक जटिल और कम अभिव्यक्तिपूर्ण दृष्टिकोण है। NMock, RhinoMocks और Moq सभी परीक्षण युगल (स्टब्स और mocks) के दो प्रकार प्रदान करते हैं:

चौखटे क्या प्रदान में अंतर स्पष्ट करने के लिए। नकली ढांचे स्टब्स और मॉल प्रदान करता है (वे उन्हें शिम कहते हैं), और दुर्भाग्य से मैक्स शामिल नहीं है।

स्टब्स: स्टब्स उपयोग किया जाता है जब आप तरीकों या गुणों के लिए एक मान प्रदान करने की आवश्यकता आदेश NMock और एमएस नकली के बीच मतभेद और समानता को समझने के लिए, यह समझना परीक्षण युगल के इन विभिन्न प्रकार क्या हैं उपयोगी है परीक्षण के तहत विधि द्वारा आपके परीक्षण युगल से पूछा जाएगा। उदाहरण के लिए, जब परीक्षण के तहत मेरी विधि ISTudentRepository परीक्षण डबल की DoStudentExist() विधि को कॉल करती है, तो मैं इसे सत्य वापस करना चाहता हूं।

NMock और एमएस नकली में स्टब्स के विचार ही है, लेकिन NMock के साथ कुछ इस तरह करना होगा:

Stub.On(mockStudentRepository).Method("DoesStudentExist").Will(Return.Value(true)); 

और MSFakes साथ आप इस तरह somethign करना होगा:

IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository() // Generated by Fakes. 
{ 
    DoesStudentExistInt32 = (studentId) => { return new Student(); } 
}; 

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

मोजे: मैक्स का उपयोग परीक्षण और इसकी निर्भरताओं के तहत आपकी विधि के बीच बातचीत को सत्यापित करने के लिए किया जाता है। NMock के साथ, आप इस के समान उम्मीदों की स्थापना ऐसा करते हैं:

Expect.Once.On(mockStudentRepository).Method("Find").With(123); 

इस कारण से भी मैं NMock से अधिक RhinoMocks और 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); 

मैं एक छोटे से जटिल होने के लिए इस दृष्टिकोण को खोजने के बाद से आप ठूंठ में कॉल ट्रैक करने के लिए और फिर इसे बाद में परीक्षा में जोर दिया है। मुझे एनएमॉक, और विशेष रूप से राइनोमोक्स मिलते हैं, उदाहरण अधिक अभिव्यक्तिपूर्ण होते हैं।

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

using (ShimsContext.Create()) 
{ 
    System.Fakes.ShimDateTime.NowGet =() => { return new DateTime(fixedYear, 1, 1); }; 
} 

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

: कुछ नकली चौखटे इन पदों पर एक नज़र लेने के लिए संबंधित चिंताओं के बारे में अधिक जानकारी के लिए

: इस अवधारणा पर एक और अधिक पूरा लेख के लिए मेरा यह पोस्ट देखें

आप यह जानना चाहते RhinoMocks में रुचि रखते हैं यहाँ एक पी है luralsight प्रशिक्षण वीडियो (पूर्ण प्रकटीकरण - मैं इस पाठ्यक्रम में लिखा था और देखे जाने पर भुगतान रॉयल्टी मिलता है, लेकिन मुझे लगता है यह तो मैं इसे यहाँ शामिल कर रहा हूँ इस चर्चा पर लागू होता है):

+11

@ जिम मैं इस बात से असहमत हूं कि एक को "उन निर्भरताओं के खिलाफ परीक्षण करने की इजाजत दी गई है जो इंजेक्शन नहीं हैं" एक बुरी बात है। इसके विपरीत, व्यावहारिक रूप से, यह क्षमता कई बिंदुहीन इंटरफेस और संबंधित "ऑब्जेक्ट वायरिंग" कॉन्फ़िगरेशन/जटिलता के साथ कोडबेस को अव्यवस्थित करने से बचने में मदद करती है। मैंने पहले से ही कुछ परियोजनाएं देखी हैं (जावा और .NET दोनों) जिनमें सैकड़ों जावा/सी # इंटरफेस थे जिनमें केवल एक ही कार्यान्वयन वर्ग था, और बेकार XML एक्सएमएल कॉन्फ़िगरेशन (स्प्रिंग डी बीन्स के लिए, या एमएस यूनिटी के लिए Web.config में) ढांचा)। ऐसी निर्भरता बेहतर * नहीं * इंजेक्शन हैं। –

+17

@Rogerio, मैंने इस परियोजना का पालन करने वाले हजारों वर्गों के साथ कई परियोजनाओं पर काम किया है और जब निर्भरता इंजेक्शन सही किया जाता है (यदि आप एक्सएमएल कॉन्फ़िगरेशन का उपयोग कर रहे हैं तो आप इसे सही नहीं कर रहे हैं, इमो), यह सरल और अपेक्षाकृत दर्द रहित है । दूसरी तरफ, मैंने उन प्रणालियों पर काम किया है जो ऐसा नहीं करते हैं और कक्षाओं के बीच युग्मन ने मुझे हमेशा महत्वपूर्ण दर्द दिया है। परीक्षण निर्भरता इंजेक्शन का उपयोग करने का कारण नहीं है (हालांकि यह एक बुरा कारण नहीं है)। असली कारण ढीला युग्मन है। एक वर्ग द्वारा लागू किए गए इंटरफेस होने से मुझे कभी दर्द नहीं हुआ है। –

+14

@ जिम, मैं एक बड़े प्लस के रूप में खराब डिजाइन का परीक्षण करने की क्षमता देखता हूं। एक बेहतर डिजाइन की दिशा में विरासत कोड को दोबारा करने से पहले आप जो करना चाहते हैं, वह लिखना परीक्षण है। –

13

मैं के रूप में इसे समझें, विजुअल स्टूडियो टीम .NET के लिए उपलब्ध विभिन्न नकली पुस्तकालयों के साथ प्रतिस्पर्धा से बचना चाहती थी। एमएस अक्सर इस तरह के कठिन फैसले का सामना करते हैं। वे क्षतिग्रस्त हैं अगर वे कुछ कार्यक्षमता प्रदान नहीं करते हैं ("एमएस हमें नकली पुस्तकालय क्यों नहीं प्रदान करता है; मॉक्स ऐसी आम आवश्यकता है?") और अगर वे ऐसा करते हैं तो शर्मिंदा है ("माइक्रोसॉफ्ट इतनी आक्रामक तरीके से क्यों काम कर रहा है और इसे चला रहा है बाजार से बाहर प्राकृतिक समर्थक? ") अक्सर, लेकिन हमेशा नहीं, वे केवल उपलब्ध और अच्छी तरह से प्राप्त प्रौद्योगिकियों के लिए अपना विकल्प प्रदान करने से रोकने का फैसला करते हैं। ऐसा लगता है कि यहां मामला है।

नकली चीज की सुविधा वास्तव में उपयोगी है। निश्चित रूप से, खतरे हैं। यह सुनिश्चित करने के लिए कुछ अनुशासन लेता है कि आप केवल जहां आवश्यक हो इसका उपयोग करें। हालांकि, यह एक बड़ा अंतर भरता है। मेरी मुख्य शिकायत यह है कि इसे केवल वीएस 2012 के अंतिम संस्करण के साथ ही दिया जाता है और इसलिए केवल .NET विकास समुदाय के उपधारा के लिए उपलब्ध होगा। अफ़सोस की बात है।

+2

नकली ढांचे प्रीमियम संस्करण के साथ भी उपलब्ध है। – AlwaysAProgrammer

0

नकली (शिम + स्टब) वस्तुओं के संबंध में, यह ऊपर अच्छी तरह से परिभाषित किया गया है, हालांकि मुझे लगता है कि अंतिम टिप्पणी में अंतिम पैराग्राफ पूरी स्थिति को अच्छी तरह से सारांशित करता है।

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

शायद आप प्रो संस्करणों पर नकली (शिम + स्टब) मेनू विकल्प देख सकते हैं, लेकिन सावधान रहें, कुछ सुंदर संभावनाएं हैं कि आप बिल्कुल कुछ भी खत्म नहीं करेंगे ... यह किसी भी संकलन त्रुटि उत्पन्न नहीं करेगा आप जानते हैं कि कुछ महत्वपूर्ण है, विकल्प सिर्फ वहां नहीं हैं, इसलिए अपना समय बर्बाद न करें ...

देव टीम में विचार करना एक महत्वपूर्ण कारक है, खासकर यदि कोई अंतिम संस्करण का उपयोग करने वाला एकमात्र व्यक्ति है, जबकि सभी अन्य प्रो संस्करण का उपयोग करता है ... दूसरी तरफ Moq आसानी से Nuget के माध्यम से स्थापित किया जा सकता है इससे कोई फर्क नहीं पड़ता कि आप किस विजुअल स्टूडियो संस्करण का उपयोग करते हैं। मुझे मोक का उपयोग करने में कोई समस्या नहीं थी, किसी भी उपकरण के साथ कुंजी यह जानना है कि उनका उपयोग किस प्रकार किया जाता है और उन्हें सही तरीके से कैसे उपयोग किया जाए;)

+1

कृपया अपने प्रश्न को छोटे पैराग्राफ में प्रारूपित करें ताकि इसे पढ़ना आसान हो। –

+0

@SirXamelot, कोड को दोबारा नहीं कर रहा है, आप .NET के आउटपुट को नहीं बदल सकते हैं स्थिर कॉल उदा। डेटटाइम.अब या Guid.NewGuid – zaitsman

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