2009-09-17 30 views
6

मैं मुख्य रूप से व्यक्तिगत उपयोग के लिए कोड लिखता हूं, लेकिन मैं मूल रूप से व्यक्तिगत उपयोग के लिए विकसित एक एप्लिकेशन (वैज्ञानिक सिमुलेशन/विज़ुअलाइज़ेशन) जारी करने पर विचार कर रहा हूं।मुख्य विधि के लिए जावा आदत

मेरी आदतों में से एक कक्षा में अलगाव में कक्षा के संचालन का परीक्षण करने के लिए कक्षाओं में एक मुख्य विधि का उपयोग करना है। मुझे लगता है कि शायद किसी भी तरह से बुरा है (इसमें कोई संदेह नहीं है कि आत्म-शिक्षण और वैज्ञानिक विकास पर्यावरण से उत्पन्न कई अन्य आदतें हैं)। हालांकि, मैंने कभी भी स्वयं-उपयोग की जाने वाली सामग्री के लिए कोई समस्या नहीं देखी है।

क्या आप सभी इस तरह की पुष्टि करने के लिए दयालु होंगे (या इनकार करते हैं) कि वैज्ञानिकों के लिए जारी किए गए आवेदन के लिए मुख्य समस्याएं एक स्रोत है (स्रोत भी खुला होगा), और यदि ऐसा है, तो क्यों?

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

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

+1

+1 अपने आप को उजागर कर रहा है ;-) – KLE

+2

मैं केएलई से सहमत हूं। बुरी आदतों के बारे में बात करना महत्वपूर्ण है ताकि आप या तो पता लगा सकें कि वे क्यों खराब हैं (और न केवल अंधेरे का पालन करें) या औचित्य दें कि वे परिस्थितियों के एक विशिष्ट सेट के तहत क्यों ठीक हो सकते हैं। –

+2

@ बिल निकली डाल दिया।मैं सटीक शब्दों को इकट्ठा नहीं कर सका, लेकिन आपने किया। आप शायद मूल अंग्रेजी बोलने वाले हैं, अच्छे संचार कौशल हैं, और निश्चित रूप से ** इसके बारे में सोचा **। _ _ धन्यवाद, और चलते रहें ... हम में से कुछ देख रहे हैं, और आपसे सीख रहे हैं ;-) – KLE

उत्तर

6

JUnit आप परीक्षण है, बस अपने साधन की तरह, लेकिन यह भी कर सकते हैं:

  • एक मुख्य आम तौर पर केवल एक तरीका है, कि बड़े असली प्राप्त कर सकते हैं; अगर केवल परीक्षण के लिए इस्तेमाल किया छोटे तरीकों निकालने, वहाँ का उपयोग करने कि नियमित रूप से कोड में तरीकों
  • परीक्षण तरीके साथ वर्ग खुद को अस्त-व्यस्त नहीं है एक जोखिम है, वे एक अलग वर्ग में हैं
  • में विरासत की अनुमति देता है परीक्षण वर्ग (मुख्य, एक स्थिर विधि के रूप में, उत्तराधिकारी या पुन: उपयोग करना असंभव है); आम तौर पर, वास्तविक परीक्षण से पहले सेटअप बहुत लंबा हो सकता है, और इसे स्वाभाविक रूप से पुन: उपयोग करना बहुत अच्छा है
  • मुख्य में कोई परिणाम नहीं है (सफलता या विफलता), केवल एक आउटपुट; आप जांच मैन्युअल उत्पादन परिणाम निर्धारित करने के लिए की जरूरत है, और संभवतः यह समझ
  • अनुमति देने के एक बार में कई परीक्षण (वर्ग, पैकेज, परियोजना, सभी) है, जो प्रतिगमन परीक्षण के लिए आवश्यक (या आप करेंगे है के निष्पादन अपने दोपहर बिताने के लिए उन्हें) एक के बाद एक
  • JUnit बॉक्स से बाहर कई अतिरिक्त सुविधाओं को उपलब्ध कराने को क्रियान्वित करने, के रूप में नजरअंदाज कर दिया, कुछ परीक्षण अंकन जांच करते हुए कि एक परीक्षण बहुत लंबा नहीं है की तरह, कई की शुरूआत UI के
  • उपलब्ध कराने आदि प्रत्येक कार्यान्वयन या सबक्लास पर कुछ परीक्षणों का पुन: उपयोग कर सकते हैं (उदा: के लिए जांच लिस्कोव प्रतिस्थापन), जो आपको बहुत सारे टेस्ट कोड बनाए रखने के बिना बहुत परीक्षण करने की अनुमति देता है।
12

अपनी कक्षा को अपनी मुख्य विधि में जांचना बुरा है क्योंकि यह कक्षा को अतिरिक्त जिम्मेदारी (परीक्षण स्वयं) देता है। टेस्ट अलग-अलग वर्गों में जाना चाहिए, अधिमानतः एक परीक्षण पुस्तकालय का उपयोग करना जैसे JUnit

मुख्य का प्रसार (मुझे यह वाक्यांश पसंद आया है) यह डेवलपर के लिए पहली बार आने पर आपके आवेदन में प्रवेश बिंदु खोजने के लिए और अधिक भ्रमित कर देता है।

+5

+1: सभी 'सार्वजनिक स्थैतिक शून्य मुख्य' को कक्षाओं में अलग किया जाना चाहिए जो लगभग कुछ और नहीं करता है। सभी "असली" प्रसंस्करण कहीं और बेहतर 'एपीआई' के साथ कहीं और होना चाहिए। ये "असली" प्रसंस्करण वस्तुओं को 'मुख्य' द्वारा तत्काल किया जाना चाहिए। –

+0

मान लें कि ठेठ डेवलपर वास्तव में एक डेवलपर नहीं है, और इसमें बहुत कम "असली" दुनिया कोडिंग आदतें हैं। मैं सराहना करता हूं कि वास्तव में डेवलपर्स के रूप में कार्यरत लोगों के लिए आपका उत्तर बिल्कुल सही है (हालांकि निश्चित रूप से मुझे कोई जानकारी नहीं है), लेकिन क्या आपको लगता है कि यह इस अजीब दर्शकों के लिए सही है? – Carl

+2

@ करल: वास्तविक दुनिया के अनुभव के साथ सामान्य डेवलपर शायद पहले से ही इस सलाह का पालन करता है, इसलिए अटूट दर्शक वास्तव में यह किसके लिए हैं। –

2

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

यह आपके कोड से परीक्षणों को स्पष्ट रूप से अलग करता है।

3

यह भयानक नहीं है, लेकिन यह दो कारणों के लिए सलाह नहीं दी है:

  1. यह उपयोगकर्ताओं चीजें आप उन्हें करने या कम से कम उन्हें विचार वे आप कुछ कर सकते हैं कि 'देने के लिए नहीं करना चाहते करने के लिए अनुमति दे सकता है डी बल्कि वे नहीं किया; और
  2. प्रभावशाली मुख्य() विधियां अक्सर यूनिट परीक्षणों के लिए एक खराब विकल्प होती हैं।

यह (2) आपको वास्तव में ध्यान केंद्रित करना चाहिए।

6

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

0

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

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

0

मैं परीक्षण उद्देश्यों के लिए सभी वर्गों में मुख्य विधियों का भी उपयोग नहीं करता। सबसे पहले, चिंताओं के नियम को अलग करने के लिए (उपयोग और परीक्षण अलग-अलग चिंताओं हैं) और क्योंकि हमारे पास परीक्षण के लिए सुरुचिपूर्ण समाधान हैं।

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

आह, मेरे दिमाग में केवल एक तिहाई पहलू है: मुख्य विधियां हमेशा सार्वजनिक होती हैं, इसलिए आपकी लाइब्रेरी का उपयोगकर्ता किसी भी समय इन तरीकों का उपयोग करने के लिए स्वतंत्र है, यहां तक ​​कि अपने आवेदन के निष्पादन के दौरान भी। इसमें भयानक दुष्प्रभाव हो सकते हैं, खासकर बहु-थ्रेडेड वातावरण में।

संबंधित मुद्दे