सिंगल बनाम एकाधिक यूनिट टेस्ट प्रोजेक्ट प्रति समाधान?

Question

मेरे पास आमतौर पर मेरे उत्पाद असेंबली और मेरी इकाई परीक्षण असेंबली के बीच 1: 1 मैपिंग है। मैं आम तौर पर कम विधानसभाओं की कुल संख्या रखने का प्रयास करें, और एक विशिष्ट समाधान कुछ की तरह लग सकता है ...

• ग्राहक
• Client.Tests
• आम (शामिल हैं (देखें, नियंत्रकों, आदि शामिल है) डेटा/सेवा अनुबंध, आम उपयोगिताएँ आदि)
• Common.Tests
• सर्वर (शामिल डोमेन, सेवा, आदि)
• Server.Tests
• Server.WebHos टी

काम पर हाल ही में, लोगों ने केवल एक यूनिट टेस्ट प्रोजेक्ट बनाम उल्लेख किया है कि वे असेंबली द्वारा उन्हें तोड़ रहे हैं। मैं दिन में वापस जानता हूं, अगर आप अपने निर्माण के हिस्से के रूप में एनसीओवर आदि चला रहे थे तो यह जीवन आसान हो गया (अब पाठ्यक्रम के मामले में नहीं)।

सिंगल बनाम एकाधिक यूनिटटेस्ट परियोजनाओं के पीछे सामान्य तर्कसंगत क्या है? समाधान में परियोजनाओं की संख्या को कम करने के अलावा, क्या एक रास्ता या दूसरे जाने का ठोस कारण है? मुझे लगता है कि यह उन "प्राथमिकता" चीजों में से एक हो सकता है, लेकिन गूगलिंग बहुत अधिक नहीं हुआ है।

Answer 1

कोई निश्चित उत्तर है क्योंकि यह सब आपके काम के साथ-साथ व्यक्तिगत स्वाद पर निर्भर करता है। हालांकि, आप निश्चित रूप से चीजों को व्यवस्थित करना चाहते हैं ताकि आप प्रभावी ढंग से पर काम कर सकें।

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

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

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

चीजों को करने के विभिन्न तरीकों की कोशिश करने के बाद यह मेरी निजी पसंद है।

मेरी राय में, बहुत अधिक होने पर चीजों को समूहीकृत करना एक अच्छी बात नहीं है। यह हो सकता है, लेकिन मैं इस चर्चा के संदर्भ में विश्वास करता हूं कि यह एक एकल परीक्षण परियोजना के लिए गलत तर्क है। अंदर कई फाइलों के साथ बहुत अधिक परीक्षण परियोजनाओं का मतलब है कि बहुत सी परीक्षण फाइलें हैं। मेरा मानना ​​है कि वास्तविक समस्या यह है कि जिस समाधान पर आप काम कर रहे हैं वह बड़ा हो रहा है। शायद "एक दुनिया" से बचने के लिए आप अन्य चीजें कर सकते हैं? :)

Answer 2

तर्क का एक हिस्सा मैं कहूंगा कि यह आपको केवल उस असेंबली को सूचीबद्ध करने के लिए मजबूर करता है जो आप परीक्षण कर रहे हैं। तो आपके यूनिट परीक्षण गलती से एकीकरण परीक्षण या बदतर में बदल नहीं जाते हैं। यह चिंताओं को अलग करने में मदद करता है।

Answer 3

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

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

फिर से, मुझे लगता है कि यह एक प्राथमिकता बात है, मैं एक निश्चित निपटान एक ही रास्ता या अन्य में सुना नहीं किया है, लेकिन वहाँ के लायक मेरी दो सेंट है ...

Answer 4

मैं वास्तव में के चरम करने के लिए जा सकते हैं यह कहकर कि यदि आप एक असेंबली का परीक्षण करने के लिए विभिन्न परियोजनाओं में अपने परीक्षणों को विभाजित करने पर विचार करते हैं, तो वह असेंबली बहुत बड़ी है .. मैं आम तौर पर छोटे, पुन: प्रयोज्य घटकों में छोटे, 1-1 मैप किए गए परीक्षणों के साथ अपनी परियोजनाओं को विभाजित करता हूं। यह निश्चित रूप से डीएलएल-ओवरफ्लो का कारण बन सकता है, और कुछ परियोजनाओं (जैसे एक वेब प्रोजेक्ट, जहां यह अलग-अलग असेंबली में नियंत्रकों को विभाजित करने के लिए तार्किक रूप से साफ नहीं है) के साथ हमेशा संभव नहीं हो सकता है। एक विचार है।

Answer 5

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

एक समाधान परियोजना को मानते हुए, उस समाधान में सबकुछ को कवर करने वाली एक परीक्षण परियोजना के साथ, उस परिदृश्य में टूट जाता है।