2013-01-15 37 views
6

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

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

मेरे परिप्रेक्ष्य से, मुझे पेश करने से मुझे परीक्षण आवश्यकताओं पर वापस लौटने और बिना किसी संकलन के कोड प्राप्त करने के लिए नए मोक्स/स्टब्स पेश किए बिना, व्यावसायिक आवश्यकताओं के अनुरूप निर्भरताओं को आवश्यक, हटाने और पेश करने की अनुमति मिल जाएगी।

क्या ऑटोमोकिंग एक अच्छी/बुरी आदत माना जाता है? क्या विशिष्ट स्थितियां हैं जब इसे इस्तेमाल किया जाना चाहिए या नहीं किया जाना चाहिए?

उत्तर

5

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

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

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

इसे सही परिदृश्यों में महत्वपूर्ण विचार और एप्लिकेशन की आवश्यकता है।

2

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

+0

मैं इसके साथ 100% पूरी तरह से सहमत हूं - यह मुख्य रूप से इसलिए आया है क्योंकि मैं ऑर्चर्ड के शीर्ष पर बनने वाली परियोजना पर काम कर रहा हूं और ऑर्चर्ड भलाई के बहुत से उपयोग का मतलब है इंजेक्शन का मतलब है (कभी-कभी बहुत सारे मेरी राय) कुछ वर्गों में निर्भरताओं की। मैंने समान निर्भरताओं को लपेटने और निर्भरताओं की संख्या में कटौती करने के लिए यहां कुछ और कारखाने बनाने की कोशिश की है, लेकिन यह अभी भी स्थानों में कमजोर है। इस उदाहरण में एक 'ऑटोमॉकिंग' कंटेनर टूटने वाले परिवर्तनों को काट देगा जो निर्भरताओं को अनिवार्य रूप से बनाता है। – levelnis

0

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

और, आईएमओ, आपको इसे नए कोड के साथ बिल्कुल उपयोग नहीं करना चाहिए।