.NET इकाई परीक्षण परियोजना संगठन

Question

आप क्या कहते हैं कि एक बड़े .NET अनुप्रयोग में यूनिट परीक्षणों का प्रबंधन करने का सबसे अच्छा तरीका है? क्या समाधान में प्रत्येक अलग परियोजना के लिए एक परीक्षण परियोजना या अन्य परियोजनाओं में सभी परीक्षणों के लिए एक बड़ी परीक्षण परियोजना बेहतर है?

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

मैं जानता हूँ कि वहाँ कुछ मॉड्यूलर परीक्षण विधानसभाओं द्वारा की पेशकश की लाभ हैं, लेकिन बहुत इसी तरह की बातों परीक्षण श्रेणियों का उपयोग कर प्राप्त किया जा सकता। संकलन कई परियोजनाओं के साथ अधिक समय लेता है, लेकिन आप उन परियोजनाओं को बहिष्कृत कर सकते हैं जिनकी आपको आवश्यकता नहीं है, जबकि यदि आपके पास एक एकल परियोजना है तो आप ऐसा नहीं कर सकते हैं, लेकिन संकलन थोड़ा कम समय लेता है।

कृपया अपने उत्तरों में प्रत्येक विकल्प के लिए फायदे/नुकसान की रूपरेखा तैयार करें। इस सवाल पर

Answer 1

फिल हैक ने यूनिट परीक्षणों की संरचना के संबंध में एक अच्छा लेख लिखा। इकाई परीक्षण लिखते समय यह मेरा व्यक्तिगत सर्वोत्तम अभ्यास बन गया है। यहां उनके लेख http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

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

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

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

Answer 2

देखो: "Best Practice: Organize Unit Tests"

हालांकि सवाल में समाधान आकार अलग है, दिशा निर्देशों लिखा वहाँ अभी भी मान्य हैं।

Answer 3

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

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

Answer 4

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

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

अब तक मुझे संदर्भों को प्रतिस्थापित करने के अलावा किसी भी प्रकार की हानि नहीं मिली है, तो आपको एक टेस्टप्रोजेक्ट का उपयोग करते समय करना होगा।