2010-06-03 12 views
61

आज मैंने जुनीट के दावों के बजाय एक जावा सम्मिलन के साथ एक जुनीट टेस्ट केस देखा- क्या दूसरे पर एक को प्राथमिकता देने के लिए महत्वपूर्ण फायदे या नुकसान हैं?जोर दें बनाम जुनीट एसेशन

+4

मुझे लगता है कि यह प्रश्न फिर से खोलना चाहिए: शीर्ष उत्तर बेहद उपयोगी है। – jakebeal

+0

जुनीट दावे और जावा 'जोर' कीवर्ड के बीच बिल्कुल तथ्यात्मक अंतर हैं। यह बिल्कुल एक राय आधारित सवाल नहीं है। –

उत्तर

78

JUnit4 में अपवाद (वास्तव में त्रुटि) एक JUnit ज़ोर द्वारा फेंका जावा assert कीवर्ड (AssertionError) द्वारा फेंका त्रुटि रूप में ही है, तो यह वास्तव में assertTrue रूप में एक ही और स्टैक ट्रेस आप नहीं कर सके 'के अलावा अन्य है अंतर मत बताओ।

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

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

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

24

मैं JUnit दावे पसंद करते हैं के रूप में वे की तुलना में एक अमीर एपीआइ निर्मित assert बयान और, अधिक महत्वपूर्ण स्पष्ट assert, जो -ea JVM तर्क की आवश्यकता के विपरीत सक्षम करने की जरूरत नहीं है।

+0

'-ea' हमेशा 'mvn test' में सक्षम है,' -ea 'की आवश्यकता नहीं है। रिचर एपी, अच्छी पकड़। कभी-कभी मुझे लगता है कि एपीआई परीक्षण में दुरुपयोग किया जाता है क्योंकि यह एप्लिकेशन (एपीआई में) का हिस्सा नहीं है, मैं इसे केवल समृद्ध तरीकों से कॉल करना पसंद करता हूं। –

0

मैं कहूंगा कि यदि आप जुनीट का उपयोग कर रहे हैं तो आपको जुनीट दावे का उपयोग करना चाहिए। assertTrue() मूल रूप से assert जैसा ही है, अन्यथा जुनीट का उपयोग क्यों करें?

+2

आप परीक्षण चलने वाले ढांचे के लिए जुनीट का उपयोग करेंगे। आवेषण वास्तव में मूल्य के एक छोटे हिस्से हैं जो जुनीट आपको देता है। 'Assert' के बिना जुनीट को अधिक बॉयलरप्लेट की आवश्यकता होगी। जुनीट के बिना 'जोर' के लिए आपको एक संपूर्ण ढांचा लिखने की आवश्यकता होगी। – Yishai

+0

मैं कह रहा था कि यदि आप उपकरण का उपयोग करने जा रहे हैं, तो टूल का उपयोग करें। जुनीट टेस्ट के मामलों में नियमित रूप से पुरानी ज़ोरदार वक्तव्य एक मूर्खतापूर्ण प्रतीत होता है। वे मेरी राय में वास्तविक कोड के साथ हैं। – CheesePls

+0

@ चेसपल्स "नियमित पुराने जोरदार बयान" वास्तव में जुनीट आवेषण से अधिक हाल ही में हैं। – dolmen

0

यह लागू नहीं हो सकता है यदि आप विशेष रूप से चमकीले और नए सामान का उपयोग करते हैं, लेकिन 1.4SE तक जावा में जोर नहीं दिया गया था। इसलिए, यदि आपको पुरानी तकनीक वाले वातावरण में काम करना चाहिए, तो आप संगतता कारणों के लिए जुनीट की तरफ झुक सकते हैं।

11

जब कोई परीक्षण विफल रहता है तो आपको अधिक जानकारी मिलती है। java.lang.AssertionError

में में java.lang.AssertionError: expected:<1> but was:<2>

बनाम

assert(1 == 2); परिणाम

assertEquals(1, 2); परिणाम अगर आप assertEquals

+2

'जोर दें 1 == 2: "1 2 नहीं है"; '। –

+0

@PeterRader जब उपयोगकर्ता सक्षम नहीं है तो जोरदार कीवर्ड आज़माएं। या बेहतर अभी तक, जुनीट दावे का उपयोग करें जो हमेशा काम करता है। –

+0

@ थॉमसडब्ल्यू जब -एए सक्षम नहीं है तो यह परीक्षण नहीं है। जुनीट का दावा हमेशा काम नहीं करता है, वे केवल तभी काम करते हैं जब आप जुनीट का उपयोग करने का निर्णय लेते हैं, और एक स्वर्ग के मामले में, एक मेवेन निर्भरता है जो केवल टेस्ट-स्कोप में होना चाहिए। हमारे यहां दो पक्ष हैं: आप क्या पसंद करते हैं? ** 1 साइड **: केवल फ्रेम-स्कोप में एक निर्भरता के रूप में, एक फ्रेमवर्क का उपयोग करें, जिसे डाउनलोड किया जाना चाहिए, ग्रहण आपको उन वर्गों में उपयोग करने देता है जो src/main-folder में नहीं हैं लेकिन वहां संकलित नहीं हैं क्योंकि मैवेन में जूनिट है केवल टेस्ट-स्कोप या ** द्वितीय साइड ** में: बिल्ड-इन सामग्री का उपयोग करें। –

5

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

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