बेस्ट प्रैक्टिस: यूनिट टेस्ट व्यवस्थित करें

Question

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

आप उन्हें ऐसे बड़े समाधान/परियोजनाओं के लिए कैसे व्यवस्थित करते हैं?

Answer 1

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

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

यदि आपको कई परीक्षण लक्ष्यों के बीच परीक्षण कोड साझा करने की आवश्यकता है, तो आप हमेशा एक सामान्यीकृत, पुन: प्रयोज्य परीक्षण API के साथ एक साझा लाइब्रेरी बना सकते हैं, जब तक कि यह किसी भी लक्षित परियोजनाओं का संदर्भ नहीं देता है।

उस ने कहा, मुझे जॉन स्कीट से सहमत होना है कि 270 परियोजनाओं के साथ एक समाधान एक संरचनात्मक गंध है जिसे पहले संबोधित किया जाना चाहिए (जब तक कि यह स्वचालित निर्माण के लिए उपयोग किए जाने वाले "सभी का निर्माण" समाधान न हो)।

Answer 2

270 परियोजनाओं के साथ एक एकल समाधान शुरू करने में समस्या की तरह लगता है। वीएस खोलने में कितना समय लगता है? :) (गंभीरता से, क्या आप या तो कुछ परियोजनाओं को एक साथ जोड़ सकते हैं या समाधान को विभाजित कर सकते हैं?)

आम तौर पर मैं यूनिट परीक्षण अपने स्वयं के प्रोजेक्ट में रखता हूं, लेकिन उसी समाधान में। प्रोजेक्ट के भीतर, उत्पादन प्रोजेक्ट के फ़ोल्डर/नेमस्पेस संरचना को मिरर करें। उदाहरण के लिए Noda Time कैसे व्यवस्थित किया गया है, इस पर एक नज़र डालें। मैं उन कंपनियों में रहा हूं जहां उन्हें एक अलग समाधान में रखा गया है, लेकिन यह वास्तव में दर्दनाक था। (उनके पास एक अच्छा कारण था: परीक्षण वीएस2005 में थे और उत्पादन कोड 2003 था।)

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

Answer 3

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