ऑब्जेक्ट मॉकिंग क्या है और मुझे इसकी आवश्यकता कब है?

जब वे इकाई परीक्षण लिख रहे होते हैं तो बहुत से लोग मॉक ऑब्जेक्ट्स का उपयोग करते हैं। मॉक ऑब्जेक्ट क्या है? मुझे कभी एक की आवश्यकता क्यों होगी? क्या मुझे मॉक ऑब्जेक्ट फ्रेमवर्क चाहिए?

0
ro fr bn
जोड़ा लेखक Michael Freidgeim, स्रोत

8 उत्तर

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

एक लोकप्रिय जिसे मैं उपयोग करना पसंद करता हूं उसे Moq कहा जाता है, लेकिन RhinoMock जैसे कई अन्य हैं और कई ऐसे जिन्हें मैं नहीं जानता।

0
जोड़ा

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

आपको वास्तव में नकली ऑब्जेक्ट ढांचे की आवश्यकता नहीं है, केवल उस कार्यक्षमता की श्रेणी का विस्तार करें जिसे आप अपने परीक्षण में चिंता नहीं करना चाहते हैं और सुनिश्चित करें कि जिस श्रेणी में आप परीक्षण कर रहे हैं वह असली चीज़ की बजाय आपके नकली का उपयोग कर सकता है (इसे पास करें एक कन्स्ट्रक्टर या सेटर या कुछ के माध्यम से।

अभ्यास तब दिखाएगा जब मैक्स सहायक होते हैं और जब वे नहीं होते हैं।

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

0
जोड़ा

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

0
जोड़ा

क्या मुझे मॉक ऑब्जेक्ट फ्रेमवर्क चाहिए?

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

यदि आप सिर्फ मॉकिंग के साथ शुरुआत कर रहे हैं, तो सीधे ढांचे में कूदना आपके सीखने की वक्र को कम से कम दोगुना करने वाला है (क्या आप वक्र को दोगुना कर सकते हैं?)। मॉकिंग फ्रेमवर्क अधिक अधिक समझ में आएंगे जब आपने कुछ परियोजनाओं को हाथ से हाथों में लिखने में बिताया है।

0
जोड़ा

ऑब्जेक्ट मॉकिंग का उपयोग निर्भरता को आपके यूनिट परीक्षण से बाहर रखने के लिए किया जाता है। कभी-कभी आपके पास "SelectPerson" जैसे परीक्षण होंगे जो डेटाबेस से किसी व्यक्ति का चयन करेगा और एक व्यक्ति ऑब्जेक्ट वापस करेगा।

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

0
जोड़ा
ऑब्जेक्ट को नकल करना आवश्यक होगा जब वस्तु को स्वयं सेट किया जा सके और यूनिट परीक्षणों में वापस भेज दिया जाए। उस परिदृश्य में जो बेहतर है और क्यों? मेरे मामले में मेरे पास एक डोमेन लेयर फ़ंक्शन है जो डीटीओ ऑब्जेक्ट का उपयोग करता है। अब यह वास्तव में एक डीटीओ ऑब्जेक्ट में .set ऑपरेशन का उपयोग करके और यूनिट परीक्षणों में इसका उपयोग करके मॉकिटो का उपयोग करके कोड लिखने के लिए काउंटर अंतर्ज्ञानी लगता है। उदाहरण - mockObject.setMessage ("हैलो") v / s Mockito.when (mockDTO.getMessage ())। फिर वापसी ("हैलो"); 10/10 बार मैं पहले दृष्टिकोण के लिए जाना चाहता हूं।
जोड़ा लेखक Ashwin, स्रोत

कई लोगों ने पहले से ही 'क्या' का जवाब दिया है, लेकिन यहां कुछ त्वरित 'whys' हैं जिन्हें मैं सोच सकता हूं:

  1. Performance

    Because unit tests should be fast, testing a component that interacts with a network, a database, or other time-intensive resource does not need to pay the penalty if it's done using mock objects. The savings add up quickly.

  2. Collaboration

    If you are writing a nicely encapsulated piece of code that needs to interact with someone else's code (that hasn't been written yet, or is in being developed in parallel - a common scenario), you can exercise your code with mock objects once an interface has been agreed upon. Otherwise your code may not begin to be tested until the other component is finished.

0
जोड़ा

यह आपको यह जांचने की अनुमति देता है कि आपकी परियोजना का एक हिस्सा बाकी चीज़ों के साथ कैसे काम करता है, पूरी चीज के निर्माण के बिना और संभावित रूप से एक महत्वपूर्ण हिस्सा खो देता है।

संपादित करें: विकिपीडिया से शानदार उदाहरण: यह आपको पहले से कोड का परीक्षण करने की अनुमति देता है, जैसे एक कार डिजाइनर एक दुर्घटना के दौरान कार के व्यवहार का परीक्षण करने के लिए एक क्रैश टेस्ट डमी का उपयोग करता है।

0
जोड़ा

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

0
जोड़ा
QAIndia
QAIndia
160 प्रतिभागियों की

QA India ! Unite Here we share job postings , prepare for interviews and share tips/techniques in QA. Please follow following guideline while sharing any job ... QA job # location : # title Company : Title : Requirement: Responsibility: Apply: