2009-02-17 8 views
6

मैं एक साधारण, अगर idiosyncractic, बाहरी सेवा से कनेक्ट कर रहा हूँ।बाहरी सेवाओं का मज़ाक उड़ाकर यूनिट परीक्षणों में सुधार कैसे हो सकता है?

मेरा मानना ​​है कि मेरे यूनिट परीक्षण उस बाहरी सेवा की उपलब्धता या कार्यान्वयन पर निर्भर नहीं होना चाहिए, इसलिए मैं इसे मजाक करना चाहता हूं।

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

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

क्या मैंने गलत मोड़ लिया है? मैं इस स्पष्ट परिपत्र को कैसे खत्म कर सकता हूं?

EDIT मैंने स्पष्ट किया है कि मुझे लगता है कि समस्या न्याय की सहायक टिप्पणियों के प्रकाश में क्या है।

उत्तर

3

मुझे आपको पहले दोहराने से बचने के लिए यूनिट परीक्षण के बारे में my two answers at another question पर जाने दें।

मुझे लगता है कि मॉकिंग आपको इस माहौल में देता है कि यह दृढ़ता से निर्दिष्ट करता है कि आप सोचते हैं कि उस बाहरी इंटरफ़ेस का व्यवहार होने वाला है। इसका मतलब है कि आपके पास एक नियंत्रित परीक्षण है (कुछ मुझे यह बाहरी सेवा हर बार बदलता है।) तो, न केवल प्रतिक्रियाओं के ज्ञात "अच्छे" अनुक्रम के साथ आप अपने कोड का परीक्षण और डीबग कर सकते हैं, लेकिन आपके पास एक दस्तावेज सेट है आप जो उम्मीद करते हैं उसके उदाहरणों के उदाहरण।

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

बिंदु, हालांकि, ऐसा कुछ है जिसके लिए आपको वास्तविक विश्वास है और जिसे आप पूरी तरह से नियंत्रित करते हैं।

+0

आह हाँ, यह है, धन्यवाद।जोखिम और रखरखाव दूर नहीं जा रहा है, तथ्य के सरल गुण से यह एक _external_ सेवा है! लेकिन अपने व्यवहार की मेरी अपेक्षाओं को व्यक्त करके, मैं अनिश्चितता को अलग करता हूं। –

+1

'मेरे दो उत्तरों पर एक और प्रश्न' का लिंक टूटा हुआ है। क्या कोई यह कह सकता है कि यह अब कहाँ रहता है? –

+0

यह काम करना चाहिए। http://stackoverflow.com/questions/513778/what-do-you-think-of-junit-style-unit-testing-do-you-favor-behaviour-driven-tes/513807#513807 –

0

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

+0

धन्यवाद - मैंने आपकी स्पष्टीकरण टिप्पणियों के प्रकाश में qu को संपादित किया है। मुझे यकीन नहीं है कि आपने मेरी अंतर्निहित चिंता का उत्तर दिया है। यदि आपके पास एक पल है, तो क्या आप एक और नजर डाल सकते हैं? चीयर्स। –

-1

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

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