2008-10-17 11 views
28

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

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

उत्तर

26

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

मॉकिंग फ्रेमवर्क हैं जो आपको इन वस्तुओं को मक्खी पर बनाने की अनुमति देते हैं और संक्षेप में आपको कुछ ऐसा कहने की अनुमति मिलती है: मुझे एक विधि foo के साथ एक ऑब्जेक्ट बनाएं जो एक int लेता है और एक बूल देता है। जब मैं 0 पास करता हूं, तो यह सच होना चाहिए। फिर आप यह सुनिश्चित करने के लिए foo() का उपयोग करने वाले कोड का परीक्षण कर सकते हैं, यह उचित रूप से प्रतिक्रिया करता है।

मार्टिन Fowler मजाक पर एक बड़ा लेख है:

+0

बहुत बढ़िया लेख लिंक। धन्यवाद –

9

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

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

6

मैं के साथ सब कुछ @Lou Franco कहते हैं और आप निश्चित रूप से परीक्षण पर उत्कृष्ट मार्टिन Fowler लेख पढ़ना चाहिए सहमत दोगुना हो जाता है कि @Lou फ्रेंको अंक आप के लिए।

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

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

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

2

यहां एक उदाहरण दिया गया है: यदि आप एक कोड लिख रहे हैं जो डेटाबेस को पॉप्युलेट करता है तो आप यह जांचना चाहेंगे कि किसी विशेष विधि ने डेटाबेस में डेटा जोड़ा है या नहीं।

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

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

नकली आपको परीक्षण एक दूसरे से स्वतंत्र रखने और स्थापित करने में आसान रखने की अनुमति देता है।

यह सिर्फ एक उदाहरण है - मुझे यकीन है कि अन्य लोग अधिक आपूर्ति कर सकते हैं।

मैं इस विषय पर अन्य योगदानकर्ताओं के साथ 100% सहमत हूं, खासकर मार्टिन फाउलर लेख की सिफारिश के साथ।

0

आपको हमारी पुस्तक में रुचि हो सकती है, http://www.growing-object-oriented-software.com/ देखें। यह जावा में है, लेकिन विचार अभी भी लागू होते हैं।

+0

यह एक टूटा हुआ लिंक है। –

+0

पुस्तक लिंक तय किया, धन्यवाद –

संबंधित मुद्दे