मेरा मानना है कि सर्वोत्तम प्रथाएं हैं जो हमें वास्तविक निर्भरताओं (इस मामले में "कारखानों") के विरुद्ध एकीकृत करने के लिए मोक्स (इस मामले में "युगल") का उपयोग करने के बारे में सोचने के लिए मार्गदर्शन करती हैं। परीक्षण पर एक बहुत अच्छी किताब है (चेतावनी: यह जावा उदाहरणों का उपयोग करती है) जो परीक्षण संचालित विकास के उद्देश्य का वर्णन करती है, और मुझे लगता है कि रेल अनुप्रयोगों में परीक्षण पर इस चर्चा में यह बहुत उपयोगी है। यह निम्नानुसार परीक्षण के इरादे का वर्णन करता है:
... परीक्षण संचालित विकास में हमारा इरादा वस्तुओं के बीच संबंध लाने के लिए नकली वस्तुओं का उपयोग करना है।
फ्रीमैन, स्टीव; प्राइस, नेट (200 9 -12-12)। बढ़ते ऑब्जेक्ट-ओरिएंटेड सॉफ्टवेयर, टेस्ट द्वारा निर्देशित (जलाने के स्थान 3878-3879)। पियरसन एजुकेशन (यूएसए)। किंडल संस्करण।
अगर हम परीक्षण चालित विकास न केवल का उपयोग करके हमसे शुरू प्रतिगमन से रोकने के लिए पर इस जोर बारे में सोचते हैं, लेकिन हमें कैसे हमारे कोड अन्य वस्तुओं के लिए इसके इंटरफेस के मामले और रिश्तों में संरचित है के बारे में सोचने में मदद करने के हम करेंगे स्वाभाविक रूप से कई मामलों में मोजे का उपयोग करें। मैं वर्णन करूंगा कि यह आपके विशिष्ट प्रश्नों पर कैसे लागू होता है।
सबसे पहले, हम मॉडल परीक्षणों में नकली वस्तुओं या वास्तविक निर्भरताओं का उपयोग करते हैं या नहीं - यदि हम कक्षा फू और बार पर निर्भरता का परीक्षण कर रहे हैं, तो हम बार के लिए एक नकली प्रतिस्थापित करना चाहेंगे। इस तरह हम बार को युग्मन के स्तर को स्पष्ट रूप से देखेंगे क्योंकि हमें उन तरीकों का नकल करना होगा जिन्हें उस पर बुलाया जाएगा। अगर हम पाते हैं कि बार का हमारा मजा जटिल है, तो यह एक संकेत है कि शायद हमें फू और बार को दोबारा करना चाहिए ताकि वे एक-दूसरे से कम हों।
इस अर्थ में कि Factory.create और Factory.build_stubbed दोनों को संबंधित वर्गों पर निर्भरता बनाने से रोकने का एक ही प्रभाव है, मुझे लगता है कि वे फैक्ट्री के साथ चिकनी हैं, दोनों विकल्पों के धीमे होने के कारण।
मेरे परीक्षणों में मैं नियंत्रकों में बाह्य निर्भरताओं का मज़ाक उड़ाते हुए बहुत ज्यादा चिंता नहीं करता हूं।मुझे पता है कि यह पूरी तरह से मजाक करने से चलने के लिए धीमा है, और आपके पास मॉडल को कंट्रोलर को स्पष्ट करने का लाभ नहीं है, लेकिन परीक्षण लिखना तेज़ है, और मैं आम तौर पर स्पष्ट करने के बारे में चिंतित नहीं हूं नियंत्रकों और उनके द्वारा प्रबंधित किए गए लगातार रिकॉर्ड के बीच संबंध। जब तक आप "पतला नियंत्रकों" के पैटर्न का पालन करते हैं, वैसे भी यहां चिंता करने के लिए बहुत तर्क नहीं होना चाहिए। अगर हमें यहां "परीक्षण गंध" का स्तर निर्दिष्ट करने की आवश्यकता है तो मैं कहूंगा कि यह मॉडल परीक्षणों की तुलना में थोड़ा कम गंध है जो अन्य कारखानों पर निर्भर करता है।
मैं कम से कम सजावट करने वालों के बारे में चिंता करने की इच्छा करता हूं जो वे सजाने वाले वर्गों की कारखानों पर निर्भर करते हैं। ऐसा इसलिए है क्योंकि परिभाषा के अनुसार सजावटी को उसी वर्ग को उसी वर्ग के रूप में बनाए रखना चाहिए जो वे सजाने वाले वर्ग के रूप में करते हैं। सजावट को अक्सर कुछ प्रकार के विरासत के साथ कार्यान्वित किया जाता है, भले ही method_missing का उपयोग करके सजावट के लिए प्रतिनिधि हो या सजावट के स्पष्ट उप-वर्गीकरण के द्वारा। इस वजह से आप अच्छी वस्तु-उन्मुख प्रोग्रामिंग के अन्य नियमों को तोड़ रहे हैं जैसे कि लिस्कोव सबस्टिट्यूशन यदि सजावटी उस चीज़ के इंटरफ़ेस से बहुत अधिक विचलित हो जाता है। जब तक आपकी सजावट अच्छी विरासत के नियमों को तोड़कर खराब तरीके से कार्यान्वित नहीं की जाती है, तब तक आप जो वर्ग सजाने के लिए तैयार होते हैं, वह पहले से मौजूद होता है, इसलिए यदि आप सजावट का परीक्षण जारी रखते हैं या स्टब्बेड पर निर्भर करते हैं तो यह चीजों को और भी बदतर नहीं बना रहा है उस चीज़ का कारखाना जो इसे सजाता है। आप सजावटी परीक्षणों में कारखानों के साथ पागल हो सकते हैं और इससे कोई फर्क नहीं पड़ता आईएमओ।
मुझे लगता है कि यह ध्यान रखना महत्वपूर्ण है कि यदि आप ज्यादातर मामलों में मोक्स पसंद करते हैं तो भी आपको कुछ एकीकरण परीक्षण होना चाहिए जो वास्तविक निर्भरताओं का उपयोग करें। आपको पता चलेगा कि ये कवर विशिष्ट उच्च-मूल्य वाले मामले हैं, जहां पृथक इकाई परीक्षण आपके वर्गों द्वारा प्रदान की गई कार्यक्षमता का अधिक कवरेज प्रदान करते हैं।
किसी भी दर पर मैं कभी-कभी उपरोक्त सभी नियमों को तोड़ता हूं और वे केवल कुछ दिशानिर्देश हैं जिन्हें मैं लेखन परीक्षणों में उपयोग करता हूं। मैं यह सुनकर उम्मीद कर रहा हूं कि अन्य लोग अपने परीक्षणों में मैक ऑब्जेक्ट्स (युगल) बनाम कारखानों (build_stubbed और वास्तव में बने) का उपयोग कैसे कर रहे हैं।
मुझे व्यक्तिगत रूप से 'FactoryGirl.build_stubbed' के बारे में भी पता नहीं था। शायद यह उत्तर की कमी बताता है। "कोड गंध" शब्द की यह या उच्च अधीनता। –