क्या जुनीट संदेश सफलता या विफलता की स्थिति बताएगा?

Question

मैं एक दावे संदेश दो तरीकों में से एक लिख सकता हूं। उन्होंने कहा सफलता:

assertEquals("objects should be identical", expected, actual); 

या तोड़ा जा रहा है की हालत बताते हुए:

assertEquals("objects aren't identical", expected, actual); 

वहाँ JUnit विशेष रूप में इस के लिए एक मानक है? यदि नहीं, तो प्रत्येक पक्ष के लिए तर्क क्या हैं?

पीएस मैंने वेब पर आलेखों को बिना स्पष्टीकरण के इन दोनों को प्रदर्शित किया है, इसलिए बस "Google खोज" कहना एक जवाब नहीं है!

[अद्यतन]

हर कोई तथ्य यह है कि मैं assertEquals इस्तेमाल किया है और इसलिए संदेश शायद बेकार है पर लटका दिया हो रही है। लेकिन निश्चित रूप से ऐसा इसलिए है क्योंकि मैं केवल प्रश्न को स्पष्ट करना चाहता था।

बजाय कल्पना यह है:

assertTrue(... big long multi-line expression ...); 

कहाँ संदेश उपयोगी है।

Answer 1

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

मुझे आमतौर पर पता चलता है कि यूनिट परीक्षण विफलता क्षणिक चीजें हैं - मैं तेजी से पता लगाऊंगा कि क्या गलत है और इसे ठीक करें। "क्या गलत है यह पता लगाने" में आमतौर पर पर्याप्त जानकारी शामिल होती है कि एक संदेश बहुत अंतर नहीं ले रहा है। ठीक है, एक मामले में जहां मैं संदेश का उपयोग कर सकते: बनाम "संदेशों के समय बिताया सोच" :)

संपादित करें "संदेश होने से बचाया समय" पर विचार करें जब वहाँ पाठ में एक कॉम्पैक्ट वर्णन जो स्पष्ट नहीं है है वस्तु के स्ट्रिंग प्रतिनिधित्व से।

उदाहरण के लिए: मिलीसेकंड के रूप में संग्रहीत तिथियों की तुलना करते समय "1 दिसंबर होने की अपेक्षित तिथि"।

मैं इस बारे में चिंता नहीं करता कि आप इसे कैसे व्यक्त करते हैं: बस सुनिश्चित करें कि यह संदेश से स्पष्ट है कि आप किस तरह से हैं। या तो "होना चाहिए" या "नहीं था" ठीक है - बस "दिसंबर 1" स्पष्ट नहीं होगा।

Answer 2

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

संदेश का लक्ष्य कुछ पूर्णता प्राप्त करने के लिए, आपकी सहायता करने के लिए है।

जाहिर है, assertEquals के मामले में यह कम महत्वपूर्ण है, लेकिन सामान्य आवेषण के मामले में संदेश महत्वपूर्ण है। संदेश को वास्तव में असफल होने के तुरंत बाद समझने के लिए पर्याप्त संदर्भ प्राप्त करने में आपकी सहायता करनी चाहिए।

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

Answer 3

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

Answer 4

JUnit की javadocs से:

Asserts that two objects are equal. If they are not an AssertionFailedError is thrown with the given message.

एपीआई के अनुसार, संदेश आप जो कुछ भी चाहते हो सकता है। मैं तर्क दूंगा कि आपके पास दो विकल्प समान हैं और दोनों अनिवार्य हैं। जोर की सफलता या विफलता पहले से ही संदेश में प्रदान की जा रही सारी जानकारी प्रदान करती है।

यह मेरे लिए है कि आपके पास कुछ भी नहीं होना चाहिए (एक ऐसा जोर है जो उद्देश्य पर एक स्ट्रिंग नहीं लेता है) या अर्थ के साथ एक संदेश शामिल है जो पहले से मौजूद है।

तो मुझे लगता है कि यह जॉन के जवाब का पुनरावृत्ति है, लेकिन यह भी एक टिप्पणी होने के लिए वर्बोज़ है।

Answer 5

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

Answer 6

यदि मैं जीनरल में कोई संदेश उपयोगी हूं, तो मैं विचार किए बिना प्रश्न का उत्तर देना चाहूंगा।

यदि कोई परीक्षण विफल रहता है, तो कुछ गलत है। मैं यह जानता हूँ। मैं जानना चाहता हूं कि यह क्यों टूटा हुआ है। यह पता लगाना बहुत आसान है क्योंकि मुझे सिर्फ टेस्ट केस और एसयूटी खोलना है। जैसा कि जॉन ने कहा, इसे ठीक करना बहुत आसान है (उम्मीद है ;-))।

लेकिन संदेश के बारे में क्या? संदेश मेरे लिए एक सलाह है, इसे हरित परीक्षण मामले में बदलने के लिए क्या किया जा सकता है। इसलिए संदेश की पाठ में दी गई सलाह, इस समस्या को ठीक करने या समस्या के बारे में कहां से पता चलाना है, तो मैं सराहना करता हूं।

एक और दिलचस्प पहलू सकारात्मक अभिव्यक्तियों का उपयोग होगा। सकारात्मक टेक्स्ट संदेशों का उपयोग करने पर विचार करना उचित है। आपके उदाहरण में, मैं Objects should be identical का उपयोग करूंगा। लेकिन यह एक छोटा कारण है।

Answer 7

कई अन्य लोगों के विपरीत मुझे लगता है कि संदेश का उपयोग कर कई कारणों से अत्यंत उपयोगी है:

1. व्यक्ति व्यक्ति जो परीक्षण लिखा नहीं हो सकता है एक असफल परीक्षण के लॉग को देख। कोड के माध्यम से पढ़ने में समय लग सकता है और समझने के लिए दावा का क्या मतलब है। एक उपयोगी संदेश समय बचाएगा।

2. यहां तक ​​कि घटना में यह परीक्षण का डेवलपर है जो लॉग देख रहा है, परीक्षण के बाद से दिन या महीने हो सकते हैं और फिर, एक संदेश समय बचा सकता है।

मेरी सलाह संदेश को अपेक्षित व्यवहार के बयान के साथ लिखना होगा।उदाहरण के लिए:

assertEquals("The method should be invoked 3 times", 3, invocationCount); 

Answer 8

JUnit एपीआई के अनुसार संदेश "AssertionError के लिए की पहचान संदेश" है, इसलिए इसकी नहीं संदेश शर्त यह है कि पूरा किया जाना चाहिए, लेकिन का वर्णन क्या गलत है वर्णन करने वाला संदेश अगर हालत 'isn टी मिले तो आपके उदाहरण में "ऑब्जेक्ट्स समान नहीं हैं" अधिक अनुरूप लगता है।

Answer 9

मैं मानता हूं कि एक संदेश प्रदान करना सहायक है और मैं हमेशा एक प्रदान करता हूं।

मेरे लिए, इसमें शामिल होने वाली उपयोगी बात यह है कि क्या गलत हो गया है - आमतौर पर शब्दों को 'चाहिए' या 'नहीं होना चाहिए' शामिल है।

उदा।, "ऑब्जेक्ट्स बराबर हैं" संदिग्ध है - क्या इसका मतलब यह है कि ऑब्जेक्ट बराबर हैं और यही कारण है कि परीक्षण विफल हुआ? या वह वस्तुएं बराबर होनी चाहिए लेकिन वे नहीं हैं? लेकिन अगर आप कहते हैं कि "ऑब्जेक्ट्स बराबर होना चाहिए" या "ऑब्जेक्ट्स बराबर नहीं होना चाहिए" तो यह स्पष्ट है कि दावा विफल क्यों हुआ।

Answer 10

मैं दो दृष्टिकोणों से इस सवाल को देखते हैं,

सबसे पहले और सबसे आम परिप्रेक्ष्य है, जो पहले से ही हमें यहाँ के सबसे द्वारा चर्चा की जा: किसी के परिप्रेक्ष्य जो लॉग देखने और ठीक करने के लिए कोशिश कर रहा है से त्रुटि: मुझे विश्वास है कि दोनों संदेश समान जानकारी प्रदान करते हैं।

दूसरा परिप्रेक्ष्य वह है जो कोड पढ़ रहा/रखता/समीक्षा कर रहा है: जैसा कि हम कोड की पठनीयता और सादगी के बारे में उम्र के बाद से बात कर रहे हैं। तो, यह भी उतना ही महत्वपूर्ण है।

हमें विश्वास है कि मेरा कोड सरल और आत्म व्याख्यात्मक होना चाहिए ताकि कोई स्पष्ट टिप्पणी की आवश्यकता न हो और मैं इसके साथ दृढ़ता से सहमत हूं।

इस दृष्टिकोण से:

assertEquals("objects should be identical", expected, actual); 
assertTrue("flag should have been set", flag); 
assertNotNull("object must not be null", object); 

ये संदेश हैं:

इन संदेशों को यह बहुत आसान पढ़ सकते हैं और कोड के माध्यम से जाने के रूप में वे त्रुटि की सूचना के साथ ही दस्तावेज के दोहरे उद्देश्य की सेवा के लिए करना नहीं तो पाठक के अनुकूल के रूप में वे अप्रत्याशित स्थिति के बारे में बात: मैं विशेष रूप से कैसे स्पॉक परीक्षण ढांचे परीक्षण है कि r को प्रोत्साहित करती है की तरह

assertEquals("objects aren't identical", expected, actual); 
assertTrue("flag is not set", flag); 
assertNotNull("object is null", object); 

Answer 11

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

assertEquals("Cloned and persisted items", mockedTiCount, clonedTis.size()); 
assertTrue("Belong to new transaction", clonedTis.stream().allMatch(ti -> ti.getTransaction().getId().equals(cloned.getId()))); 
assertNotEquals("Which has a different ID", t.getId(), cloned.getId()); 
assertEquals("While the originals are left intact", mockedTiCount, transactionItemRepository.findByTransactionId(t.getId()).size()); 

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

Answer 12

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

http://junit.sourceforge.net/javadoc/org/junit/Assert.html#assertTrue(java.lang.String, boolean)

Parameters: 
message - the identifying message for the AssertionError (null okay) 
condition - condition to be checked