मॉक ऑब्जेक्ट
ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, नकली ऑब्जेक्ट सिम्युलेटेड ऑब्जेक्ट होते हैं जो नियंत्रित तरीकों से वास्तविक वस्तुओं के व्यवहार की नकल करते हैं, अक्सर सॉफ़्टवेयर परीक्षण पहल के हिस्से के रूप में। एक प्रोग्रामर आम तौर पर किसी अन्य वस्तु के व्यवहार का परीक्षण करने के लिए एक नकली ऑब्जेक्ट बनाता है, ठीक उसी तरह जैसे एक कार डिजाइनर वाहन प्रभावों में मानव के गतिशील व्यवहार का अनुकरण करने के लिए क्रैश टेस्ट डमी का उपयोग करता है। यह तकनीक सामान्य प्रोग्रामिंग में भी लागू है।
प्रेरणा
एक इकाई परीक्षण में, नकली वस्तुएं जटिल, वास्तविक वस्तुओं के व्यवहार का अनुकरण कर सकती हैं और इसलिए तब उपयोगी होती हैं जब किसी वास्तविक वस्तु को इकाई परीक्षण में शामिल करना अव्यावहारिक या असंभव होता है। यदि किसी वस्तु में निम्नलिखित में से कोई भी विशेषता है, तो उसके स्थान पर नकली वस्तु का उपयोग करना उपयोगी हो सकता है:
- वस्तु गैर-नियतात्मक एल्गोरिदम | गैर-नियतात्मक परिणाम (उदाहरण के लिए वर्तमान समय या वर्तमान तापमान) प्रदान करती है;
- इसमें ऐसी स्थितियां हैं जिन्हें बनाना या पुन: उत्पन्न करना मुश्किल है (उदाहरण के लिए नेटवर्क त्रुटि);
- यह धीमा है (उदाहरण के लिए एक संपूर्ण डेटाबेस, जिसे परीक्षण से पहले तैयार करना होगा);
- यह अभी तक अस्तित्व में नहीं है या व्यवहार बदल सकता है;
- इसमें विशेष रूप से परीक्षण उद्देश्यों के लिए जानकारी और विधियों को शामिल करना होगा (और इसके वास्तविक कार्य के लिए नहीं)।
उदाहरण के लिए, एक अलार्म घड़ी प्रोग्राम जिसके कारण एक निश्चित समय पर घंटी बजती है, उसे समय सेवा से वर्तमान समय मिल सकता है। इसका परीक्षण करने के लिए, परीक्षण को यह जानने के लिए अलार्म बजने तक इंतजार करना होगा कि उसने घंटी सही ढंग से बजाई है या नहीं। यदि वास्तविक समय सेवा के स्थान पर मॉक टाइम सेवा का उपयोग किया जाता है, तो इसे वास्तविक समय की परवाह किए बिना घंटी बजने का समय (या कोई अन्य समय) प्रदान करने के लिए प्रोग्राम किया जा सकता है, ताकि अलार्म घड़ी कार्यक्रम का अलगाव में परीक्षण किया जा सके।
तकनीकी विवरण
मॉक ऑब्जेक्ट का इंटरफ़ेस (कंप्यूटिंग)#सॉफ़्टवेयर इंटरफ़ेस ऑब्जेक्ट ओरिएंटेड भाषाओं में वास्तविक ऑब्जेक्ट की तरह ही होता है, जिसकी वे नकल करते हैं, जिससे क्लाइंट ऑब्जेक्ट को इस बात से अनजान रहने की अनुमति मिलती है कि वह वास्तविक ऑब्जेक्ट का उपयोग कर रहा है या नकली ऑब्जेक्ट का। कई उपलब्ध मॉक ऑब्जेक्ट फ्रेमवर्क प्रोग्रामर को यह निर्दिष्ट करने की अनुमति देते हैं कि मॉक ऑब्जेक्ट पर कौन सी और किस क्रम में विधि (कंप्यूटर विज्ञान) लागू की जाएगी और उन्हें कौन सा पैरामीटर (कंप्यूटर विज्ञान) पारित किया जाएगा, साथ ही कौन से मान लौटाए जाएंगे। . इस प्रकार, नेटवर्क सॉकेट जैसी जटिल वस्तु के व्यवहार की नकल एक नकली वस्तु द्वारा की जा सकती है, जिससे प्रोग्रामर को यह पता लगाने की अनुमति मिलती है कि परीक्षण की जा रही वस्तु विभिन्न प्रकार की स्थितियों में उचित रूप से प्रतिक्रिया करती है या नहीं।
नकली, नकली, और स्टब्स
पूरे साहित्य में नकली, नकली और परीक्षण स्टब्स के बीच वर्गीकरण अत्यधिक असंगत है।[1][2][3][4][5][6] हालाँकि, साहित्य में सुसंगत बात यह है कि वे सभी एक ही इंटरफ़ेस को उजागर करके परीक्षण वातावरण में एक उत्पादन वस्तु का प्रतिनिधित्व करते हैं।
नकली, नकली या स्टब में से कौन सा सबसे सरल है, यह असंगत है, लेकिन सबसे सरल हमेशा पूर्व-व्यवस्थित प्रतिक्रिया देता है (जैसा कि एक विधि स्टब में होता है)। स्पेक्ट्रम के दूसरी तरफ, सबसे जटिल वस्तु पूरी तरह से तर्क, अपवाद आदि के साथ एक उत्पादन वस्तु का अनुकरण करेगी। नकली, नकली, या स्टब तिकड़ी में से कोई भी ऐसी परिभाषा में फिट बैठता है या नहीं, फिर से, असंगत है साहित्य।
उदाहरण के लिए, जटिलता स्पेक्ट्रम के दो सिरों के बीच एक नकली, नकली, या स्टब विधि कार्यान्वयन में प्रत्येक कॉल के संदर्भ की जांच करने के लिए अभिकथन (कंप्यूटिंग) हो सकता है। उदाहरण के लिए, एक मॉक ऑब्जेक्ट उस क्रम का दावा कर सकता है जिसमें उसके तरीकों को बुलाया जाता है, या विधि कॉल में डेटा की स्थिरता का दावा कर सकता है।
इकाई परीक्षण की कला पुस्तक में[7] मॉक को एक नकली वस्तु के रूप में वर्णित किया जाता है जो यह तय करने में मदद करता है कि किसी वस्तु के साथ बातचीत हुई या नहीं, यह सत्यापित करके परीक्षण विफल हुआ या उत्तीर्ण हुआ। बाकी सब कुछ एक आधार के रूप में परिभाषित किया गया है। उस पुस्तक में, नकली ऐसी कोई भी चीज़ है जो वास्तविक नहीं है, जो, उनके उपयोग के आधार पर, या तो स्टब्स या नकली हो सकती है।
अपेक्षाएँ निर्धारित करना
एक उदाहरण पर विचार करें जहां एक प्राधिकरण उपप्रणाली का मज़ाक उड़ाया गया है। मॉक ऑब्जेक्ट एक कार्यान्वित करता है isUserAllowed(task : Task) : boolean[8] वास्तविक प्राधिकरण वर्ग में उसका मिलान करने की विधि। यदि यह एक को भी उजागर करता है तो कई फायदे मिलते हैं isAllowed : boolean संपत्ति, जो वास्तविक वर्ग में मौजूद नहीं है। यह परीक्षण कोड को आसानी से यह अपेक्षा निर्धारित करने की अनुमति देता है कि उपयोगकर्ता को अगली कॉल में अनुमति दी जाएगी या नहीं, और इसलिए किसी भी मामले में सिस्टम के बाकी हिस्सों के व्यवहार का आसानी से परीक्षण किया जा सकता है।
इसी तरह, मॉक-ओनली सेटिंग्स यह सुनिश्चित कर सकती हैं कि उप-सिस्टम पर आने वाली कॉल के कारण अपवाद हैंडलिंग, हैंग (कंप्यूटिंग) बिना जवाब दिए, या वापस आ जाएगी। null आदि। इस प्रकार, फ्रंट-एंड और बैक-एंड | बैक-एंड उप-प्रणालियों में यथार्थवादी गलती स्थितियों के साथ-साथ उनकी अपेक्षित प्रतिक्रियाओं के लिए क्लाइंट-सर्वर मॉडल व्यवहार का विकास और परीक्षण करना संभव है। इतनी सरल और लचीली मॉक प्रणाली के बिना, इनमें से प्रत्येक स्थिति का परीक्षण करना इतना श्रमसाध्य हो सकता है कि उन पर उचित विचार नहीं किया जा सके।
लॉग स्ट्रिंग लिखना
एक नकली डेटाबेस ऑब्जेक्ट save(person : Person) विधि में अधिक (यदि कोई हो) कार्यान्वयन कोड नहीं हो सकता है। यह अस्तित्व की जांच कर सकता है और शायद सहेजने के लिए पास किए गए व्यक्ति ऑब्जेक्ट के डेटा सत्यापन (ऊपर नकली बनाम नकली चर्चा देखें), लेकिन इसके अलावा कोई अन्य कार्यान्वयन नहीं हो सकता है।
यह एक गँवाया हुआ अवसर है। मॉक विधि सार्वजनिक लॉग स्ट्रिंग में एक प्रविष्टि जोड़ सकती है। प्रविष्टि को व्यक्ति द्वारा सहेजे जाने से अधिक की आवश्यकता नहीं है,[9]: 146–7 या इसमें व्यक्ति वस्तु उदाहरण से कुछ विवरण शामिल हो सकते हैं, जैसे नाम या आईडी। यदि परीक्षण कोड मॉक डेटाबेस से जुड़े संचालन की विभिन्न श्रृंखलाओं के बाद लॉग स्ट्रिंग की अंतिम सामग्री की भी जांच करता है, तो यह सत्यापित करना संभव है कि प्रत्येक मामले में डेटाबेस की अपेक्षित संख्या में सेव किया गया है। यह अन्यथा अदृश्य प्रदर्शन-घटाने वाले बग ढूंढ सकता है, उदाहरण के लिए, जहां एक डेवलपर, डेटा खोने से घबराकर, बार-बार कॉल को कोडित करता है save() जहां सिर्फ एक ही काफी होता.
परीक्षण-संचालित विकास में उपयोग
परीक्षण-संचालित विकास (टीडीडी) पद्धति के साथ काम करने वाले प्रोग्रामर सॉफ्टवेयर लिखते समय नकली वस्तुओं का उपयोग करते हैं। नकली वस्तुएं इंटरफ़ेस (कंप्यूटर विज्ञान) की आवश्यकताओं को पूरा करती हैं, और अधिक जटिल वास्तविक वस्तुओं के लिए खड़ी होती हैं; इस प्रकार वे प्रोग्रामर को जटिल अंतर्निहित या सहयोगी वर्ग (कंप्यूटर विज्ञान) को बुलाए बिना एक क्षेत्र में यूनिट परीक्षण | यूनिट-परीक्षण कार्यक्षमता लिखने की अनुमति देते हैं।[9]: 144–5 मॉक ऑब्जेक्ट का उपयोग करने से डेवलपर्स को अपनी निर्भरता के बारे में चिंता किए बिना परीक्षण के तहत सिस्टम के व्यवहार पर अपने परीक्षणों को केंद्रित करने की अनुमति मिलती है। उदाहरण के लिए, विशेष अवस्थाओं में मौजूद कई वस्तुओं के आधार पर एक जटिल एल्गोरिदम का परीक्षण वास्तविक वस्तुओं के स्थान पर नकली वस्तुओं का उपयोग करके स्पष्ट रूप से व्यक्त किया जा सकता है।
जटिल मुद्दों और चिंताओं के इस अलगाव से प्राप्त लाभों के अलावा, इसमें व्यावहारिक गति के मुद्दे भी शामिल हैं। टीडीडी का उपयोग करके सॉफ़्टवेयर का एक यथार्थवादी टुकड़ा विकसित करने में आसानी से कई सौ यूनिट परीक्षण शामिल हो सकते हैं। यदि इनमें से कई डेटाबेस, वेब सेवाओं और अन्य इंटर-प्रोसेस संचार|आउट-ऑफ-प्रोसेस या संगणक संजाल सिस्टम के साथ संचार को प्रेरित करते हैं, तो यूनिट परीक्षणों का सूट नियमित रूप से चलाने के लिए बहुत धीमा हो जाएगा। इसके परिणामस्वरूप डेवलपर में बुरी आदतें और टीडीडी के बुनियादी सिद्धांतों को बनाए रखने में अनिच्छा उत्पन्न होती है।
जब नकली वस्तुओं को वास्तविक वस्तुओं से बदल दिया जाता है, तो एंड-टू-एंड कार्यक्षमता को और अधिक परीक्षण की आवश्यकता होगी। ये यूनिट परीक्षण के बजाय एकीकरण परीक्षण होंगे।
सीमाएँ
नकली वस्तुओं का उपयोग यूनिट परीक्षणों को परीक्षण किए जा रहे कोड के कार्यान्वयन के साथ निकटता से जोड़ सकता है। उदाहरण के लिए, कई नकली ऑब्जेक्ट फ्रेमवर्क डेवलपर को परीक्षण की जा रही वास्तविक वस्तु द्वारा नकली ऑब्जेक्ट विधियों को लागू किए जाने के क्रम और संख्या की जांच करने की अनुमति देते हैं; परीक्षण किए जा रहे कोड की बाद में रीफैक्टरिंग के कारण परीक्षण विफल हो सकता है, भले ही सभी नकली ऑब्जेक्ट विधियां अभी भी पिछले कार्यान्वयन के अनुबंध का पालन करती हों। यह दर्शाता है कि इकाई परीक्षणों को किसी विधि के आंतरिक कार्यान्वयन के बजाय उसके बाहरी व्यवहार का परीक्षण करना चाहिए। यूनिट परीक्षणों के एक सूट के हिस्से के रूप में नकली वस्तुओं के अत्यधिक उपयोग से रखरखाव की मात्रा में नाटकीय वृद्धि हो सकती है जिसे सिस्टम विकास के दौरान पुनर्रचना के दौरान परीक्षणों पर स्वयं करने की आवश्यकता होती है। विकास के दौरान ऐसे परीक्षणों के अनुचित रखरखाव से बग छूट सकते हैं जो अन्यथा इकाई परीक्षणों द्वारा पकड़े जाएंगे जो वास्तविक कक्षाओं के उदाहरणों का उपयोग करते हैं। इसके विपरीत, केवल एक विधि का मज़ाक उड़ाने के लिए संपूर्ण वास्तविक कक्षा स्थापित करने की तुलना में बहुत कम कॉन्फ़िगरेशन की आवश्यकता हो सकती है और इसलिए रखरखाव की आवश्यकता कम हो सकती है।
मॉक ऑब्जेक्ट को उस ऑब्जेक्ट के व्यवहार को सटीक रूप से मॉडल करना होता है जिसका वे मॉक कर रहे हैं, जिसे प्राप्त करना मुश्किल हो सकता है यदि मॉक किया जा रहा ऑब्जेक्ट किसी अन्य डेवलपर या प्रोजेक्ट से आता है या यदि इसे अभी तक लिखा भी नहीं गया है। यदि व्यवहार को सही ढंग से मॉडल नहीं किया गया है, तो यूनिट परीक्षण एक पास दर्ज कर सकता है, भले ही यूनिट परीक्षण उन्हीं परिस्थितियों में रन टाइम पर विफलता होगी, जिससे यूनिट परीक्षण गलत हो जाएगा।[10]
यह भी देखें
- विधि (कंप्यूटर_प्रोग्रामिंग)#सार विधियाँ
- डमी कोड
- विधि आधार
- दोबारा परीक्षण करें
संदर्भ
- ↑ "Let's speak the same language (Fake, Stubs and Mocks)".
- ↑ "behind the times: Mocks and Stubs aren't Spies". 21 October 2007.
- ↑ "Mocks, Fakes, Stubs and Dummies at XUnitPatterns.com".
- ↑ "What's the difference between a mock & stub?".
- ↑ "What's the difference between faking, mocking, and stubbing?".
- ↑ Feathers, Michael (2005). "Sensing and separation". लीगेसी कोड के साथ प्रभावी ढंग से कार्य करना. NJ: Prentice Hall. p. 23 et seq. ISBN 0-13-117705-2.
- ↑ Osherove, Roy (2009). "Interaction testing with mock objects et seq". इकाई परीक्षण की कला. Manning. ISBN 978-1-933988-27-6.
- ↑ These examples use a nomenclature that is similar to that used in Unified Modeling Language
- ↑ 9.0 9.1 Beck, Kent (2003). उदाहरण के द्वारा परीक्षण-संचालित विकास. Boston: Addison Wesley. ISBN 0-321-14653-0.
- ↑ InJava.com to Mocking | O'Reilly Media
बाहरी संबंध
- 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.
