क्या मुझे यूनिट परीक्षण हैशकोड/बराबर/toString परीक्षण करना चाहिए?

Question

जब जावा वर्गों लेखन, यह नहीं असामान्य अपने आईडीई का उपयोग कर तरीकों उत्पन्न करने के लिए है इस तरह के

• toString()
• equals()
• hashCode()

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

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

कुछ कवरेज टूल फ़िल्टरिंग का समर्थन करते हैं (यानी कोबर्टुरा), अन्य (यानी जैकोको) नहीं। लेकिन कवरेज टूल केवल एक लक्षण प्रकट करते हैं - अवांछित कोड - और इसलिए मैं नहीं पूछ रहा हूं कि लक्षण को दबाने/अनदेखा करना है, लेकिन मूल कारण से कैसे निपटना है।

प्रश्न है: क्या मुझे इन विधियों के लिए यूनिट परीक्षण लिखना चाहिए?

• यदि हां, तो ऐसा करने के अच्छे कारण क्या हैं? और एक समझदार दृष्टिकोण क्या है?
• यदि नहीं, तो क्यों नहीं?

मैं सामान्य रूप में उत्पन्न कक्षाओं के लिए नहीं कह रहा हूँ, JAXB POJOs, WS-ग्राहक आदि, जो आसानी से स्वचालित रूप से उत्पन्न किया जा सकता है और कवरेज विश्लेषण से बाहर रखा गया है।

Answer 1

आप उन तरीकों उत्पन्न, तो आप शायद यह भी परीक्षण उत्पन्न करनी चाहिए यह ;-) के लिए

इसे हाथ से उन तरीकों का परीक्षण करने बोझिल हो सकता है लेकिन यदि आप अपने परीक्षण के साथ सुनिश्चित करना चाहते हैं पर निर्भर करता है, यह हो सकता है उन तरीकों का परीक्षण करने के लायक भी हो। काउंटर-प्रश्न: क्या आप लॉग-स्टेटमेंट का परीक्षण करेंगे?

यह वास्तव में उस पर निर्भर करता है जो आप पूरा करने की कोशिश कर रहे हैं। कुछ लोग कहेंगे: नहीं, दूसरों कह सकते हैं: करो।

कुछ कारणों के बारे में सोच इस तरह के तरीकों का परीक्षण करने के लिए नहीं:

• कोड उत्पन्न होता है और खेतों की बहुत सारी हो सकती है। इसका परीक्षण करने से कई सारे संयोजन हो सकते हैं जो लिखने/बनाए रखने के लिए बोझिल होंगे और शायद जेनरेटर पहले से ही पर्याप्त परीक्षण कर चुका था? ;-)
• आपको इसके लिए परीक्षण लागू करके कोई मूल्य नहीं मिलता है। आपके toString() का उपयोग केवल लॉग या डीबगर द्वारा किया जाएगा, इसलिए आपको परवाह नहीं है।
• तुम पर भरोसा है कि उत्पन्न कोड hashcode के लिए पर्याप्त सुरक्षित है और equals

कारण इस तरह के तरीकों का परीक्षण करने के लिए:

• सुनिश्चित करने के लिए है कि परिणाम की उम्मीद है के रूप में
• आप यह सुनिश्चित करें कि चाहते हैं यदि आप उन तरीकों को पुन: उत्पन्न करते हैं, तो यह पिछले विधि कार्यान्वयन को तोड़ता नहीं है
• आप लॉगिंग के अलावा अपने toString() -method का उपयोग करते हैं और सी नहीं चाहते हैं वहां दिखाने के लिए चीजें हैं। जैसा कि हल्क ने कहा था, आप यह भी सुनिश्चित करना चाहते हैं कि कुछ चीजें लॉग में भी दिखाई न दें।

लेकिन इन्हें इसके बजाय बनाया गया था। आखिरी परियोजनाओं में मैंने toString() और equals या hashCode का परीक्षण नहीं किया था, क्योंकि शायद ही कभी जरूरी नहीं माना गया था और सभी सहमत थे।

यह सब करने के लिए नीचे आ सकता है: कैसे सुरक्षित आप अपने कोड होना चाहते हैं और कितना लायक

Answer 2

बाह्य पुस्तकालयों के लिए समान - आपको इसे उत्पन्न करते समय equals और hashcode विधियों का परीक्षण नहीं करना चाहिए। कवरेज की जांच करने वाले प्लगइन में उत्पन्न स्रोतों को अनदेखा करने के लिए कुछ तंत्र होना चाहिए।

जेनरेट कोड का परीक्षण करने का कोई अच्छा कारण नहीं है, यदि आपकी कक्षा, या पूरी कक्षा में यह जेनरेट विधि है तो कोई फर्क नहीं पड़ता।

यदि आप बाहरी तंत्र के आधार पर विश्वास करते हैं कि यह ठीक से बनाया गया है।

Answer 3

ये विधियां स्वयं बेकार हैं। यदि आप संग्रह में उन वर्गों का उपयोग नहीं करते हैं (जैसे HashSet/HashMap) या यदि आप समानता के लिए उन वर्ग उदाहरणों की जांच नहीं करते हैं - आपको यूनिट परीक्षण की आवश्यकता नहीं है। और, इस मामले में, मैं सिर्फ प्लगइन को अक्षम कर दूंगा जो उन्हें उत्पन्न करता है, जैसा कि @ बाईबाई प्रस्तावित है।

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

Answer 4

आईडीई जेनरेट की गई समस्या हैशकोड/बराबर है कि यह ऑब्जेक्ट के साथ सिंक से बाहर हो सकता है (उदाहरण के लिए जब आप नए फ़ील्ड जोड़ते हैं)। इसलिए मैं हैशकोड और बराबर के लिए परीक्षण बनाने की सलाह दूंगा।

यह निश्चित रूप से हाथ से लिखने के लिए उप-इष्टतम होगा। आप इन्हें एक-लाइनर बनाने के लिए EqualsVerifier प्रोजेक्ट जैसे स्वचालित टूल का उपयोग कर सकते हैं।

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