JUnit वर्गों को विशेष परीक्षण पैकेज में अलग करना?


118

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

लेकिन अब मैं खुद बैठकर इसे आजमाना चाहता हूं। मेरा एक प्रश्न है कि मुझे आशा है कि केवल एक सरल उत्तर की आवश्यकता होगी।

आप अपने JUnit परीक्षण कक्षाओं और अपने वास्तविक कोड को कैसे व्यवस्थित करते हैं? मैं मुख्य रूप से पैकेज संरचना के बारे में बात कर रहा हूं, लेकिन नोट की कोई अन्य अवधारणा भी उपयोगी होगी।

क्या आप org.myname.project.test। * में परीक्षण कक्षाएं लगाते हैं और org.myname.project? में सामान्य कोड? * क्या आप सामान्य कक्षाओं के साथ-साथ परीक्षण कक्षाएं भी लगाते हैं? क्या आप टेस्ट प्रत्यय के बजाय वर्ग के नामों को प्रत्यय देना पसंद करते हैं?

मुझे पता है कि ऐसा लगता है कि मुझे इस तरह की चिंता नहीं करनी चाहिए, लेकिन मैं एक बहुत ही संगठन-केंद्रित व्यक्ति हूं। मैं लगभग उस तरह का व्यक्ति हूं जो वास्तव में चीजों को प्राप्त करने के बजाय, जो किया जाता है, उस पर नज़र रखने के लिए अधिक समय बिताता है।

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


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


जवाबों:


154

मैं परीक्षण कक्षाओं को उसी पैकेज में रखना पसंद करता हूं, जिस पर वे परियोजना परीक्षण करते हैं, लेकिन एक अलग भौतिक निर्देशिका में, जैसे:

myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java

मावेन परियोजना में यह इस तरह दिखेगा:

myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java

इसमें मुख्य बिंदु यह है कि मेरी परीक्षण कक्षाएं (और परीक्षण!) पैकेज-स्कोप वर्ग और सदस्यों तक पहुंच सकती हैं।

जैसा कि ऊपर दिए गए उदाहरण से पता चलता है, मेरी परीक्षा कक्षाओं में Testप्रत्यय के रूप में परीक्षण किए गए वर्ग का नाम है । यह उन्हें जल्दी से खोजने में मदद करता है - सौ परीक्षण वर्गों में से एक जोड़े के बीच खोज करने की कोशिश करना बहुत मज़ेदार नहीं है, जिनके प्रत्येक नाम के साथ शुरू होता है Test...

@ रिकेट्स की टिप्पणी से प्रेरित अपडेट : इस तरह परीक्षण कक्षाएं (आम तौर पर) अपने परीक्षण मित्र के बाद प्रोजेक्ट नामों के वर्ग-आधारित वर्णानुक्रम सूची में सही दिखाई देती हैं। (मज़ेदार है कि मुझे इस दिन से लाभ हो रहा है, बिना होश के एहसास हुआ कि कैसे ...)

Update2: मावेन की तरह बहुत सारे डेवलपर्स (अपने आप को), लेकिन ऐसा लगता है कि कम से कम कई लोग हैं जो नहीं करते हैं। IMHO यह "मुख्यधारा" जावा परियोजनाओं के लिए बहुत उपयोगी है (मैं लगभग 90% परियोजनाओं को इस श्रेणी में डालूंगा ... लेकिन अन्य 10% अभी भी एक बड़ा अल्पसंख्यक है)। यह उपयोग करना आसान है अगर कोई मावेन सम्मेलनों को स्वीकार कर सकता है; हालाँकि यदि नहीं, तो यह जीवन को एक दुखद संघर्ष बनाता है। मावेन को चींटी पर समाजीकृत कई लोगों के लिए समझाना मुश्किल लगता है, क्योंकि यह स्पष्ट रूप से सोच का एक बहुत अलग तरीका है। (स्वयं, चींटी का इस्तेमाल कभी नहीं किया, दोनों की तुलना नहीं कर सकते।) एक बात सुनिश्चित है: यह प्रक्रिया में एक प्राकृतिक, प्रथम श्रेणी के कदम का परीक्षण इकाई (और एकीकरण) करता है, जो डेवलपर्स को इस आवश्यक अभ्यास को अपनाने में मदद करता है।


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

उत्कृष्ट सम्मेलन +1
व्हिस्की सियार

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

जबकि यह सम्मेलन दिलचस्प है, जब आप परीक्षण सूट बढ़ता है तो आप क्या करते हैं? उदाहरण के लिए मान लें कि आपके पास कक्षा में 6 विधियाँ हैं, प्रत्येक विधि में 10 परीक्षण हैं। क्या आपकी कक्षा में 60 टेस्ट हैं? मैं आमतौर पर परीक्षण वर्ग (प्रति विधि एक परीक्षण वर्ग) को वश में करता हूं। इसके साथ समस्या यह है कि आपको अपने परीक्षण पैकेज में बहुत सी कक्षाएं मिल सकती हैं।
mmalmeida

1
Eclipse में @Thick_propheT: प्रोजेक्ट नाम पर राइट क्लिक करें, नया - अन्य ... क्लिक करें, फिर जावा फ़ोल्डर के अंदर सोर्स फोल्डर चुनें। इसे "परीक्षण" नाम दें। फिर यदि आप ऊपर दिए गए अधिवेशन का अनुसरण करना चाहते हैं, तो इस परीक्षण फ़ोल्डर में एक नया पैकेज जोड़ें, जिसका नाम उसी वर्ग के पैकेज के रूप में है, जिसके लिए आप परीक्षण प्रकरण लिखना चाहते हैं, तो पैकेज में एक नया JUnit Test Case (स्थित में) जोड़ें जावा-जूनिट फ़ोल्डर जब आप नया-अन्य करते हैं ...)। उस नए विज़ार्ड में आप परीक्षण किए जा रहे वर्ग को निर्दिष्ट कर सकते हैं और अपने टेस्ट केस को "टेस्ट" प्रत्यय के साथ उसी नाम के रूप में नाम दे सकते हैं
inor

15

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


12

मैं मावेन का उपयोग करता हूं । मावेन को बढ़ावा देने वाली संरचना है: -

src/main/java/org/myname/project/MyClass.java

src/test/java/org/myname/project/TestMyClass.java

यानी टेस्ट के साथ एक टेस्ट क्लास, टेस्ट के तहत क्लास के नाम से जुड़ा हुआ है, मुख्य परीक्षा के समानांतर निर्देशिका संरचना में है।

एक ही पैकेज में परीक्षण कक्षाएं होने का एक फायदा (जरूरी नहीं कि निर्देशिका हालांकि) आप मॉक टेस्ट ऑब्जेक्ट्स का निरीक्षण या इंजेक्शन लगाने के लिए पैकेज-स्कोप तरीकों का लाभ उठा सकते हैं।


18
हालांकि मैं यह था <class>Test.java, नहींTest<class>.java
माइक रायलैंडर

2
मावेन अचूक प्लगिन प्रलेखन के अनुसार , मावेन या तो पैटर्न को स्वीकार करेगा ।
एलिजा वुडवर्ड

3
मेरा तर्क है कि <class>Test.javaनामकरण योजना IDE खोज सुविधाओं का उपयोग करते समय मुख्य वर्ग और परीक्षण वर्ग दोनों को करीब दिखाती है, जो इसे थोड़ा बेहतर बनाता है Test<class>.java
क्रिस्टोफेमल

1
@christopheml मैं सहमत हूँ, कि मैं अब क्या करूँ।
मार्टिन

इसने इंटेलीज के लिए काम किया। MyClassTest.java ने काम नहीं किया।
user2761431
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.