मॉक ऑब्जेक्ट

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, मॉक ऑब्जेक्ट एक प्रकार के सिम्युलेटेड ऑब्जेक्ट होते हैं जो नियंत्रित तरीकों से वास्तविक ऑब्जेक्ट के व्यवहार की नकल (मॉक) करते हैं, प्रायः सॉफ़्टवेयर परीक्षण पहल के हिस्से के रूप में करते हैं। एक प्रोग्रामर सामान्यतः किसी अन्य ऑब्जेक्ट के व्यवहार का परीक्षण करने के लिए एक मॉक ऑब्जेक्ट बनाता है, ठीक उसी तरह जैसे एक कार डिजाइनर वाहन प्रभावों में मानव के गतिशील व्यवहार का अनुकरण करने के लिए क्रैश टेस्ट डमी का उपयोग करता है। यह तकनीक सामान्य प्रोग्रामिंग में भी लागू है।

प्रेरणा

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

• ऑब्जेक्ट गैर-नियतात्मक एल्गोरिदम | गैर-नियतात्मक परिणाम (उदाहरण के लिए वर्तमान समय या वर्तमान तापमान) प्रदान करती है;
• इसमें ऐसी स्थितियां हैं जिन्हें बनाना या पुन: उत्पन्न करना कठिन है (उदाहरण के लिए नेटवर्क त्रुटि);
• यह धीमा है (उदाहरण के लिए एक संपूर्ण डेटाबेस, जिसे परीक्षण से पहले तैयार करना होगा);
• यह अभी तक अस्तित्व में नहीं है या व्यवहार बदल सकता है;
• इसमें विशेष रूप से परीक्षण उद्देश्यों के लिए जानकारी और विधियों को सम्मिलित करना होगा (और इसके वास्तविक कार्य के लिए नहीं)।

उदाहरण के लिए, एक अलार्म घड़ी प्रोग्राम जिसके कारण एक निश्चित समय पर घंटी बजती है, उसे समय सेवा से वर्तमान समय मिल सकता है। इसका परीक्षण करने के लिए, परीक्षण को यह जानने के लिए अलार्म बजने तक इंतजार करना होगा कि उसने घंटी सही ढंग से बजाई है या नहीं। यदि वास्तविक समय सेवा के स्थान पर मॉक टाइम सेवा का उपयोग किया जाता है, तो इसे वास्तविक समय की परवाह किए बिना घंटी बजने का समय (या कोई अन्य समय) प्रदान करने के लिए प्रोग्राम किया जा सकता है, ताकि अलार्म घड़ी कार्यक्रम का अलगाव में परीक्षण किया जा सके।

तकनीकी विवरण

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

मॉक, फेक, और स्टब्स

पूरे साहित्य में मॉक, मॉक और परीक्षण स्टब्स के बीच वर्गीकरण अत्यधिक असंगत है। हालाँकि, साहित्य में सुसंगत बात यह है कि वे सभी एक ही इंटरफ़ेस को उजागर करके परीक्षण वातावरण में एक उत्पादन ऑब्जेक्ट का प्रतिनिधित्व करते हैं।

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

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

द आर्ट ऑफ़ यूनिट टेस्टिंग पुस्तक में मॉक को एक मॉक ऑब्जेक्ट के रूप में वर्णित किया जाता है जो यह तय करने में मदद करता है कि किसी ऑब्जेक्ट के साथ बातचीत हुई या नहीं, यह सत्यापित करके परीक्षण विफल हुआ या उत्तीर्ण हुआ। बाकी सब कुछ एक आधार के रूप में परिभाषित किया गया है। उस पुस्तक में, मॉक ऐसी कोई भी चीज़ है जो वास्तविक नहीं है, जो, उनके उपयोग के आधार पर, या तो स्टब्स या मॉक हो सकती है।

अपेक्षाएँ निर्धारित करना

एक उदाहरण पर विचार करें जहां एक प्राधिकरण उपप्रणाली का मज़ाक उड़ाया गया है। मॉक ऑब्जेक्ट एक कार्यान्वित करता है isUserAllowed(task : Task) : boolean वास्तविक प्राधिकरण वर्ग में उसका मिलान करने की विधि। यदि यह एक को भी उजागर करता है तो कई फायदे मिलते हैं isAllowed : boolean संपत्ति, जो वास्तविक वर्ग में उपस्थित नहीं है। यह परीक्षण कोड को आसानी से यह अपेक्षा निर्धारित करने की अनुमति देता है कि उपयोगकर्ता को अगली कॉल में अनुमति दी जाएगी या नहीं, और इसलिए किसी भी स्थिति में सिस्टम के बाकी हिस्सों के व्यवहार का आसानी से परीक्षण किया जा सकता है।

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

लॉग स्ट्रिंग लिखना

मॉक डेटाबेस ऑब्जेक्ट save(person : Person) विधि में अधिक (यदि कोई हो) कार्यान्वयन कोड नहीं हो सकता है। यह अस्तित्व की जांच कर सकता है और शायद सहेजने के लिए पास किए गए व्यक्ति ऑब्जेक्ट के डेटा सत्यापन (ऊपर मॉक बनाम मॉक चर्चा देखें), लेकिन इसके अतिरिक्त कोई अन्य कार्यान्वयन नहीं हो सकता है।

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

परीक्षण-संचालित विकास में उपयोग

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

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

जब मॉक ऑब्जेक्टओं को वास्तविक ऑब्जेक्टओं से बदल दिया जाता है, तो एंड-टू-एंड कार्यक्षमता को और अधिक परीक्षण की आवश्यकता होगी। ये यूनिट परीक्षण के बजाय एकीकरण परीक्षण होंगे।

सीमाएँ

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

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

यह भी देखें

• विधि (कंप्यूटर_प्रोग्रामिंग)#सार विधियाँ
• डमी कोड
• विधि आधार
• दोबारा परीक्षण करें

बाहरी संबंध

• Tim Mackinnon (8 September 2009). "A Brief History of Mock Objects". Mockobjects.com/.
• Test Doubles: a section of a book on unit testing patterns.
• All about mock objects! Portal concerning mock objects
• "Using mock objects for complex unit tests". IBM developerWorks. 16 October 2006. Archived from the original on 4 May 2007.
• Unit testing with mock objects IBM developerWorks
• Mocks Aren't Stubs (Martin Fowler) Article about developing tests with Mock objects. Identifies and compares the "classical" and "mockist" schools of testing. Touches on points about the impact on design and maintenance.
• Mock exam test is a practice test that helps you prepare for a real exam. This is 100% free all mock exam test or online model exam test.