हाल के साक्षात्कार के दौरान मुझे पूछा गया कि क्यों कोई मॉक ऑब्जेक्ट बनाना चाहता है। मेरा जवाब कुछ ऐसा हुआ, "डेटाबेस ले लो - यदि आप टेस्ट कोड लिख रहे हैं, तो आप नहीं चाहते कि वह परीक्षण उत्पादन डेटाबेस में लाइव हो जाए जहां वास्तविक संचालन किया जाएगा।"नकली ऑब्जेक्ट्स क्यों बनाएं?
प्रतिक्रिया के आधार पर, मेरा जवाब स्पष्ट रूप से साक्षात्कारकर्ता की तलाश में नहीं था। एक बेहतर जवाब क्या है?
मैं इस तरह संक्षेप में प्रस्तुत करेंगे:
एक साक्षात्कार में, मुझे लगता है कि मजाक सहित की सलाह देते हैं और भी बेहतर है डेवलपर्स निर्भरता इंजेक्शन उपयोग करते हैं, एक बार यह आपको अधिक नियंत्रण रखने की अनुमति देता है, और परीक्षणों को अधिक आसानी से बनाता है।
टीम में काम करते समय नकली वस्तुओं/कार्यों भी उपयोगी हो सकते हैं। यदि आप कोड बेस के एक हिस्से पर काम कर रहे हैं जो कि कोड बेस के किसी भिन्न भाग पर निर्भर करता है जिसके लिए कुछ और ज़िम्मेदार है - जो अभी भी लिखा जा रहा है या अभी तक लिखा नहीं गया है - एक नकली वस्तु/कार्य उपयोगी है आपको एक अनुमानित आउटपुट दे रहा है ताकि आप आगे बढ़ सकें, बिना किसी व्यक्ति को अपना हिस्सा पूरा करने के लिए इंतजार किए बिना काम कर रहे हैं।
जब यूनिट परीक्षण, प्रत्येक परीक्षण को एक ऑब्जेक्ट का परीक्षण करने के लिए डिज़ाइन किया गया है। हालांकि सिस्टम में अधिकांश ऑब्जेक्ट्स में अन्य ऑब्जेक्ट्स होंगे जिनके साथ वे बातचीत करते हैं। मॉक ऑब्जेक्ट्स इन अन्य वस्तुओं के डमी कार्यान्वयन होते हैं, जो परीक्षण के तहत वस्तु को अलग करने के लिए उपयोग किए जाते हैं।
इसका लाभ यह है कि किसी यूनिट परीक्षण जो असफल होते हैं, आम तौर पर परीक्षण के तहत वस्तु को समस्या को अलग करते हैं। कुछ मामलों में समस्या नकली वस्तु के साथ होगी, लेकिन उन समस्याओं को पहचानने और ठीक करने के लिए सरल होना चाहिए।
नकली वस्तुओं के लिए कुछ सरल यूनिट परीक्षण भी लिखना एक विचार हो सकता है।
आमतौर पर उन्हें नकली डेटा एक्सेस परत बनाने के लिए उपयोग किया जाता है ताकि यूनिट परीक्षण डेटा स्टोर से अलगाव में चलाया जा सके।
अन्य उपयोग एमवीसी पैटर्न में नियंत्रक ऑब्जेक्ट का परीक्षण करते समय उपयोगकर्ता इंटरफ़ेस को नकल करने के लिए हो सकता है। यह UI घटकों के बेहतर स्वचालित परीक्षण की अनुमति देता है जो कुछ हद तक उपयोगकर्ता इंटरैक्शन को अनुकरण कर सकता है।
एक उदाहरण:
public interface IPersonDAO
{
Person FindById(int id);
int Count();
}
public class MockPersonDAO : IPersonDAO
{
// public so the set of people can be loaded by the unit test
public Dictionary<int, Person> _DataStore;
public MockPersonDAO()
{
_DataStore = new Dictionary<int, Person>();
}
public Person FindById(int id)
{
return _DataStore[id];
}
public int Count()
{
return _DataStore.Count;
}
}
बस यहाँ ठीक उत्तर देने के लिए पर जोड़ने के लिए, नकली वस्तुओं ऊपर से नीचे या नीचे-ऊपर संरचनात्मक प्रोग्रामिंग (भी OOP) में किया जाता है। वे ऊपरी स्तर के मॉड्यूल (जीयूआई, तर्क प्रसंस्करण) को डेटा प्रदान करने या नकली आउटपुट के रूप में कार्य करने के लिए हैं।
शीर्ष-नीचे दृष्टिकोण पर विचार करें: आप पहले एक जीयूआई विकसित करते हैं, लेकिन एक जीयूआई के पास डेटा होना चाहिए। तो आप एक नकली डेटाबेस बनाते हैं जो डेटा के std :: vector <> को वापस लौटाता है। आपने रिश्ते के 'अनुबंध' को परिभाषित किया है। डेटाबेस ऑब्जेक्ट के अंदर क्या चल रहा है - जब तक मेरी जीयूआई सूची एक std :: vector <> मुझे खुशी है। यह नकली उपयोगकर्ता लॉगिन जानकारी प्रदान करने के लिए जा सकता है, जो भी आपको GUI काम करने के लिए आवश्यक है।
नीचे-नीचे दृष्टिकोण पर विचार करें। आपने एक पार्सर लिखा है जो सीमित पाठ फ़ाइलों में पढ़ता है। आप कैसे जानते हैं कि यह काम कर रहा है या नहीं? आप उन ऑब्जेक्ट्स के लिए एक नकली 'डेटा-सिंक' लिखते हैं और वहां डेटा को सत्यापित करने के लिए रूट करते हैं (हालांकि आमतौर पर) कि डेटा सही ढंग से पढ़ा जाता है। अगले स्तर पर मॉड्यूल के लिए 2 डेटा स्रोतों की आवश्यकता हो सकती है, लेकिन आपने केवल एक ही लिखा है।
और नकली वस्तुओं को परिभाषित करते समय, आपने रिश्ते के अनुबंध को भी परिभाषित किया है। इसका प्रयोग अक्सर परीक्षण संचालित प्रोग्रामिंग में किया जाता है। आप टेस्ट केस लिखते हैं, इसे काम करने के लिए नकली ऑब्जेक्ट्स का उपयोग करते हैं, और अक्सर नहीं, मॉक ऑब्जेक्ट का इंटरफ़ेस अंतिम इंटरफ़ेस बन जाता है (यही कारण है कि आप मॉक ऑब्जेक्ट के इंटरफेस को शुद्ध अमूर्त वर्ग में अलग करना चाहते हैं) ।
आशा इस मदद करता है
यहाँ a few situations where mocking is indispensabl ई कर रहे हैं:
+1 धन्यवाद – k3b
मैं यहां एक अलग दिशा जाऊंगा। ऊपर वर्णित सभी चीजों को झुकाव/फिक्र करना, लेकिन शायद साक्षात्कारकर्ता नकली वस्तु के रूप में मोजे के बारे में सोच रहे थे जो परीक्षा उत्तीर्ण या विफल होने का कारण बनता है। मैं इसे xUnit terminology पर आधारित कर रहा हूं। इससे state testing verses behavior/interaction testing के बारे में कुछ चर्चा हो सकती है।
जो उत्तर वे खोज रहे हैं वह यह है: कि एक नकली वस्तु एक स्टब से अलग है। एक स्टब परीक्षण के तहत विधि के लिए एक निर्भरता emulates। एक स्टब को परीक्षण विफल होने का कारण नहीं बनना चाहिए। एक नकली यह और यह भी जांचता है कि इसे कैसे और कब कहा जाता है। मोक्स अंतर्निहित व्यवहार के आधार पर पास या असफल होने का परीक्षण करते हैं। परीक्षण के दौरान डेटा पर कम निर्भर होने का इसका लाभ है, लेकिन विधि के कार्यान्वयन के लिए इसे अधिक बारीकी से बांधना।
बेशक यह अनुमान है, यह अधिक संभावना है कि वे चाहते हैं कि आप स्टबिंग और डीआई के लाभों का वर्णन करें।
एक अलग दृष्टिकोण लेने के लिए (के रूप में मुझे लगता है कि अच्छी तरह से mocks उपरोक्त में शामिल किया गया है):
"एक डेटाबेस ले लो - आप परीक्षण कोड लिख रहे हैं, तो आप उस परीक्षण करने के लिए लाइव को झुका नहीं चाहते हो सकता है उत्पादन डेटाबेस जहां वास्तविक संचालन किया जाएगा।"
आईएमओ उदाहरण के उपयोग को बताने का एक बुरा तरीका है। आप परीक्षण के दौरान या बिना परीक्षण के दौरान कभी भी" प्रोड डेटाबेस तक इसे हुक नहीं करेंगे "। प्रत्येक डेवलपर के पास परीक्षण करने के लिए डेवलपर-स्थानीय डेटाबेस होना चाहिए। और फिर आप परीक्षा वातावरण डेटाबेस पर आगे बढ़ेंगे, फिर शायद यूएटी और अंत में प्रोड। आप लाइव डेटाबेस का उपयोग करने से बचने के लिए मजाक नहीं कर रहे हैं, आप इस बात का मजाक कर रहे हैं कि कक्षाएं जो सीधे डेटाबेस पर निर्भर नहीं हैं, आपको डेटाबेस स्थापित करने की आवश्यकता नहीं है।
अंत में (और मैं स्वीकार करता हूं कि मुझे इस पर कुछ टिप्पणियां मिल सकती हैं) आईएमओ डेवलपर स्थानीय डेटाबेस यूनिट परीक्षणों के दौरान हिट करने के लिए एक वैध चीज़ है। आपको केवल उस कोड का परीक्षण करना चाहिए जो सीधे डेटाबेस के साथ इंटरैक्ट करता है और मोजे का उपयोग करता है जब तुम टी हो स्टिंग कोड जो अप्रत्यक्ष रूप से डेटाबेस तक पहुंचता है।
बेशक, मॉक ऑब्जेक्ट्स के * खराब * पक्ष पर, यह तथ्य यह है कि जब वास्तविक वर्ग इंटरफ़ेस बदलता है तो किसी को मोक्स ढूंढने और अपडेट करने के लिए भागना पड़ता है और इसी दौरान उन सभी "सफल" परीक्षण झूठ बोलते हैं। –
यदि आपके परीक्षणों में से एक इंटरफेस को सत्यापित करने में शामिल नहीं है तो इसे कम किया जा सकता है। वह परीक्षण विफल रहता है, आप जानते हैं कि आपके मोजे गलत होंगे। –
लेकिन यह इस तथ्य को नहीं बदलेगा कि इंटरफ़ेस के ग्राहक टूट गए हैं। – Gutzofter