हार्ड-कोडेड मॉक ऑब्जेक्ट्स बनाम फ्रेमवर्क

Question

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

मान लीजिए कि हमारे पास GetEmployeeById नामक विधि के साथ एक IEMployeeRepository इंटरफ़ेस है।

public interface IEmployeeRepository 
{ 
    Employee GetEmployeeById(long id); 
} 

हम आसानी से इस बात का एक नकली बना सकते हैं:

public class MockEmployeeRepository : IEmployeeRepository 
{ 
    public Employee GetEmployeeById(long id) 
    { 
     Employee employee = new Employee(); 
     employee.FirstName = "First"; 
     employee.LastName = "Last"; 
     ... 
     return employee; 
    } 
} 

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

Answer 1

यह एक मॉक नहीं है, यह एक स्टब है। स्टबिंग के लिए, आपका उदाहरण पूरी तरह से स्वीकार्य है।

मार्टिन Fowler से:

Mocks हैं हम यहाँ के बारे में बात कर रहे हैं: वस्तुओं उम्मीदों जो कॉल वे प्राप्त करने के लिए उम्मीद कर रहे हैं की एक विनिर्देश फार्म के साथ पहले से प्रोग्राम किया।

जब आप कुछ मजाक कर रहे होते हैं, तो आप आमतौर पर "सत्यापित करें" विधि कहते हैं। मजाक उड़ाता है और स्टब्स http://martinfowler.com/articles/mocksArentStubs.html

Answer 2

के बीच अंतर कुछ के लिए इस पर

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

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

Answer 3

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

Answer 4

मैं उन्हें हाथ से लिख रहा हूं। मुझे मोक का उपयोग करने में परेशानी हो रही थी, लेकिन फिर मैंने TDD: Introduction to Moq पढ़ा, और मुझे लगता है कि मैं शास्त्रीय बनाम नकली दृष्टिकोण के बारे में जो कहता हूं उसे प्राप्त करता हूं। मैं इस शाम को मोक को एक और कोशिश कर दूंगा, और मुझे लगता है कि "नकली" दृष्टिकोण को समझने से मुझे मोक को मेरे लिए बेहतर काम करने की ज़रूरत होगी।

Answer 5

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

Psuedocode:

//Unit Test One 

MockObject.Expect(m => m.GetData()).Return(null); 

//Unit Test Two 

MockObject.Expect(m => m.GetData()).Return(new MyClass()); 

//Unit Test Three 

MockObject.Expect(m => m.GetData()).ThrowException(); 

Answer 6

मुझे लगता है कि हाथ से डमी वस्तुओं लेखन के बीच या एक रूपरेखा का उपयोग करके चुनाव घटकों के प्रकार है कि आप परीक्षण कर रहे हैं पर एक बहुत निर्भर करता है।

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

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

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

मेरे लिए, जिन परियोजनाओं के लिए नकली ढांचे की आवश्यकता है, वे सिस्टम-प्रोग्रामिंग प्रकृति (जैसे डेटाबेस या वेब इंफ्रास्ट्रक्चर प्रोजेक्ट्स, या एक व्यावसायिक अनुप्रयोग में निम्न स्तर की नलसाजी) के लगभग हमेशा अनिवार्य थे। अनुप्रयोग-प्रोग्रामिंग परियोजनाओं के लिए, मेरा अनुभव यह रहा है कि दृष्टि में कुछ झटके थे।

यह देखते हुए कि हम हमेशा जितना संभव हो सके गंदे निम्न-स्तर के बुनियादी ढांचे के विवरण छिपाने का प्रयास करते हैं, ऐसा लगता है कि हमें मकड़ियों से कहीं अधिक सरल स्टब्स रखना चाहिए।