2010-11-05 11 views
10

मेरे पास एक प्रोजेक्ट है जिसमें मैं इकाई परीक्षण और टीडीडी प्रथाओं को सीखने की कोशिश कर रहा हूं। मुझे लगता है कि मुझे काफी उलझन में आने वाले मामलों में मिल रहा है, जहां मैं एक उपयोगिता वर्ग के लिए लंबे समय तक मोज़े लगा रहा हूं जिसका व्यावहारिक रूप से हर जगह उपयोग किया जाता है।क्या टीडीडी में मजाक करने के बजाए 'वास्तविक' उपयोगिता वर्ग का उपयोग करना स्वीकार्य है?

जो मैंने यूनिट परीक्षण के बारे में पढ़ा है, यदि मैं MyClass का परीक्षण कर रहा हूं, तो मुझे किसी भी अन्य कार्यक्षमता (जैसे UtilityClass द्वारा प्रदान किया गया) का मज़ाक उड़ाया जाना चाहिए। क्या यह स्वीकार्य है (यह मानते हुए कि यूटिलिटी क्लास के पास परीक्षणों का एक व्यापक सेट है) केवल सभी अलग-अलग परीक्षण मामलों के लिए मैक्स स्थापित करने के बजाय उपयोगिता क्लास का उपयोग करने के लिए?

संपादित करें: उन चीजों में से एक जिसके लिए मैं बहुत सेटअप कर रहा हूं। मैं विभिन्न स्थानों में विभिन्न वस्तुओं के साथ एक नक्शा मॉडलिंग कर रहा हूं। मेरे उपयोगिता वर्ग पर सामान्य तरीकों में से एक GetDistance के बीच है। मैं उन तरीकों का परीक्षण कर रहा हूं जिनके प्रभाव उनके व्यक्तिगत गुणों के आधार पर चीजों पर प्रभाव डालते हैं, उदाहरण के लिए एक परीक्षण जो किसी बिंदु की 5 इकाइयों और 3 वर्ष से अधिक उम्र के भीतर सभी वस्तुओं का चयन करता है, को कई परीक्षणों की आवश्यकता होगी (पुरानी वस्तुओं को सीमा में प्राप्त किया जाता है, पुरानी वस्तुओं को अनदेखा करता है सीमा के अनुसार, श्रेणी में युवा वस्तुओं को अनदेखा करता है, प्रत्येक मामले के गुणकों के साथ सही ढंग से काम करता है) और उन सभी परीक्षणों को 'GetDistanceBetween' विधि के सेटअप की आवश्यकता होती है। GetDistanceBetween (लगभग हर एक) का उपयोग करने वाली प्रत्येक विधि से गुणा करें और अलग-अलग परिस्थितियों में विधि को वापस आने वाले विभिन्न परिणाम, और यह बहुत सेटअप हो जाता है।

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

उत्तर

20

नियम "सब कुछ नकली" नहीं है बल्कि "परीक्षण सरल" है। मॉकिंग का उपयोग किया जाना चाहिए यदि

  1. आप उचित प्रयास के साथ एक उदाहरण नहीं बना सकते हैं (पढ़ें: आपको एक विधि कॉल करने की आवश्यकता है लेकिन उदाहरण बनाने के लिए, आपको एक कार्यकारी डेटाबेस, एक डीबी कनेक्शन और पांच अन्य कक्षाओं की आवश्यकता है)।
  2. अतिरिक्त कक्षाओं का निर्माण महंगा है।
  3. अतिरिक्त कक्षाओं (वर्तमान समय या किसी डेटाबेस से प्राथमिक चाबियां) अस्थिर मान
+1

+1 "परीक्षण को सरल बनाएं" पर जोर देने के लिए +1 –

1

नहीं, यह स्वीकार्य नहीं है क्योंकि अब आप अलगाव में कक्षा का परीक्षण नहीं कर रहे हैं जो इकाई परीक्षण के सबसे महत्वपूर्ण पहलुओं में से एक है। आप इस उपयोगिता के प्रति अपनी निर्भरता के साथ परीक्षण कर रहे हैं भले ही उपयोगिता के अपने परीक्षणों का सेट हो। नकली वस्तुओं के निर्माण को सरल बनाने के लिए आप एक नकली ढांचे का उपयोग कर सकते हैं। यहाँ कुछ लोकप्रिय विकल्प हैं:

बेशक

अगर इस उपयोगिता वर्ग निजी है और उसके बाद ही परीक्षण के अंतर्गत वर्ग के दायरे के भीतर इस्तेमाल किया जा सकता आप इसे नकली करने की ज़रूरत नहीं है।

+1

अलगाव में एक वर्ग का परीक्षण अवास्तविक है। यदि आप वास्तव में इसे धक्का देना चाहते हैं, तो आपको java.lang.String भी नकल करना होगा। –

+1

@ एरॉन, सहमत हुए, जब मैं अलगाव में था, तो मेरा मतलब है कि डेवलपर ने लिखा है कोड के अलगाव में। –

+0

मैं पहले से ही Moq का उपयोग कर रहा हूं, लेकिन फिर भी - अगर मुझे विधि कॉल के लिए विशिष्ट प्रतिक्रिया की आवश्यकता है, तो मुझे उन्हें सेट अप करने की आवश्यकता है। चीजें अधिक जटिल हो रही हैं क्योंकि सेटअप के मामले लंबे और लंबे हो रहे हैं। –

4

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

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

+0

हां। जब यूटिलिटी यूआरएल की तरह बाहरी संसाधनों से जुड़ती है, तो आपको उस पर नकल करना चाहिए। – freeman

9

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

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

उस व्यवहार के हिस्से के रूप में, आपकी कक्षा कुछ सहयोगी कक्षाओं का उपयोग करना चाह सकती है। आप इन्हें नकल कर सकते हैं।

यदि आपकी उपयोगिता कक्षाएं आपके वर्ग के व्यवहार का मुख्य हिस्सा हैं, और आपकी कक्षा के पास कोई मूल्य नहीं है या इसका व्यवहार उनके बिना कोई समझ नहीं आता है, तो उन्हें बाहर न करें।

हारून डिगुल्ला का जवाब बहुत अच्छा है; ।

  1. सहयोग वर्ग के व्यवहार जटिल और वर्ग में आपकी रुचि है के व्यवहार से स्वतंत्र है

  2. का निर्माण: मैं के रूप में इन सिद्धांतों के अनुसार अपने जवाब में से प्रत्येक के अलग तरीके से व्यक्त करता हूँ सहयोगी वर्ग आपकी कक्षा का एक मूल्यवान पहलू नहीं है और आपको अपनी कक्षा की ज़िम्मेदारी का हिस्सा बनने की आवश्यकता नहीं है।

  3. सहयोगी वर्ग संदर्भ प्रदान करता है जो आपकी कक्षा के व्यवहार को बदलता है, और इसलिए आप इसका उपयोग कैसे कर सकते हैं और आप किस तरह के व्यवहार की उम्मीद कर सकते हैं इसके उदाहरणों में खेलते हैं।

आशा है कि समझ में आता है! यदि आपको यह पसंद आया, तो बीडीडी पर एक नज़र डालें जो इस तरह की शब्दावली का प्रयोग "परीक्षण" से कहीं अधिक है।

+0

"और आपकी कक्षा के पास कोई मूल्य नहीं है या इसका व्यवहार उनके बिना कोई समझ नहीं आता है, तो उन्हें मजाक न करें" - तो अंक के बीच की दूरी प्राप्त करने के मेरे उदाहरण में, जहां दूरी के कार्य का एक महत्वपूर्ण निर्धारण भाग है जिस विधि का मैं परीक्षण कर रहा हूं, आप कहेंगे 'इसे मजाक मत करो'? –

+0

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

1

हां, यह स्वीकार्य है। क्या महत्वपूर्ण है कि यूटिलिटी क्लास पूरी तरह से यूनिट परीक्षण किया जाए और परीक्षण के तहत कक्षा या यूटिलिटी क्लास की वजह से परीक्षण विफल होने पर अंतर करने में सक्षम हो।

अलगाव में एक वर्ग का परीक्षण करना एक पर्यावरण में, एक पर्यावरण में परीक्षण करना है जहां कोई नियंत्रण करता है कि वस्तुएं कैसे व्यवहार करती हैं।
बनाने के लिए एक परीक्षण सेटअप में बहुत से ऑब्जेक्ट्स एक संकेत है कि पर्यावरण बहुत बड़ा हो रहा है और इस प्रकार पर्याप्त नियंत्रित नहीं है। नकली वस्तुओं पर वापस जाने के लिए समय आ गया है।

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

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