क्या बहुत से अभिकथन कोड गंध हैं?

Question

मुझे यूनिट टेस्टिंग और टीडीडी के साथ वास्तव में प्यार हो गया है - मैं संक्रमित संक्रमित हूं।

हालांकि, यूनिट परीक्षण का उपयोग आम तौर पर सार्वजनिक तरीकों के लिए किया जाता है। कभी-कभी हालांकि मुझे निजी तरीकों में भी कुछ मान्यताओं-अभिकथनों का परीक्षण करना पड़ता है, क्योंकि उनमें से कुछ "खतरनाक" हैं और रिफैक्टरिंग आगे मदद नहीं कर सकता है। (मुझे पता है, परीक्षण चौखटे निजी तरीकों का परीक्षण करने की अनुमति देते हैं)।

इसलिए यह मेरी आदत बन गई कि एक निजी पद्धति की पहली और अंतिम पंक्ति दोनों ही हैं।

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

क्या कोई कोड गंध के रूप में बहुत अधिक अभिकथनों के बारे में सोच सकता है?

Comments

क्या ये दावे जारी होने या बंद होने के आसार हैं?

— जे.के.

मैं मुख्य रूप से जावा के साथ काम करता हूं जहां मुखरता को मैन्युअल रूप से सक्षम करना पड़ता है।

— फ़्लोरेंट्स तल्साई

बस यह पाया "नीचे कीड़े पर नज़र रखने से

— Asserts

आप "बहुत सारे" को कैसे परिभाषित करते हैं?

— जाइलम

@haylem "बहुत अधिक" दावे हैं यदि कोई अन्य प्रोग्रामर कोड पढ़ता है और कहता है "मैं इन सिद्धांतों से थक गया हूं"।

— फ्लोरेंट्स त्लेसई

Answer 1

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

उन्हें केवल टिप्पणियों का उपयोग करने से बेहतर माना जाता है, क्योंकि जब भी वे चलते हैं, तो वे सक्रिय रूप से मान्यताओं की जांच करते हैं।

Comments

बहुत अच्छी बात!

— फ्लोरेंट्स त्लेसई

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

— यम मार्कोविच

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

— ओलेक्सी

मेरे लिए कोड में अभिकथन इकाई परीक्षण अभिकथन के पूरक हैं। आपके पास 100% परीक्षण कवरेज नहीं होगा और कोड में दावे आपको तेजी से असफल इकाई परीक्षणों को कम करने में मदद करेंगे।

— सेबस्टियनजिगर

Answer 2

ऐसा लगता है कि आप डिज़ाइन-बाय-कॉन्ट्रैक्ट को हाथ से करने की कोशिश कर रहे हैं ।

DbC करना एक अच्छा विचार है, लेकिन आपको कम से कम ऐसी भाषा पर स्विच करने पर विचार करना चाहिए जो इसे मूल रूप से समर्थन करती हो (जैसे कि एफिल ) या कम से कम अपने प्लेटफॉर्म के लिए एक कॉन्ट्रैक्ट फ्रेमवर्क का उपयोग करें (उदाहरण के लिए Microsoft कोड कॉन्ट्रैक्ट .NET के लिए)बहुत अच्छा है, यकीनन वहाँ सबसे परिष्कृत अनुबंध रूपरेखा, एफिल से भी अधिक शक्तिशाली है)। इस तरह, आप अनुबंधों की शक्ति का बेहतर लाभ उठा सकते हैं। उदाहरण के लिए, एक मौजूदा ढांचे का उपयोग करके, आप अपने दस्तावेज़ में अनुबंधों को एक सतह पर रख सकते हैं या एक IDE (जैसे .NET के लिए कोड अनुबंध IntelliSense में दिखाए जाते हैं और, यदि आपके पास वीएस अल्टिमेट है, तो संकलित समय पर एक स्वचालित प्रमेय कहावत द्वारा सांख्यिकीय रूप से जाँच की जा सकती है। आप टाइप करते हैं, इसी तरह कई जावा कॉन्ट्रैक्ट फ्रेमवर्क में जावाडॉक डॉकलेट होते हैं जो स्वचालित रूप से आपके जावाडॉक एपीआई डॉक्यूमेंटेशन में कॉन्ट्रैक्ट निकाल देंगे)।

और यहां तक ​​कि अगर यह पता चला है कि आपकी स्थिति में इसे मैन्युअल रूप से करने का कोई विकल्प नहीं है, तो आप अब कम से कम यह जानते हैं कि इसे क्या कहा जाता है, और इसके बारे में पढ़ सकते हैं।

तो, संक्षेप में: यदि आप वास्तव में डीबीसी कर रहे हैं, भले ही आप इसे नहीं जानते हैं, तो वे दावे पूरी तरह से ठीक हैं।

Answer 3

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

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

मुझे नहीं लगता कि आपको रिटर्न मापदंडों पर जोर देना चाहिए (जब तक कि आपके पास स्पष्ट रूप से एक अपरिवर्तनीय नहीं है जो आप पाठक को समझना चाहते हैं)। यह भी unittests का काम है।

व्यक्तिगत रूप से मुझे assertजावा में बयान पसंद नहीं है , क्योंकि उन्हें बंद किया जा सकता है और फिर यह एक झूठी सुरक्षा है।

Comments

+1 के लिए "मुझे जावा में मुखर कथन पसंद नहीं है, क्योंकि उन्हें बंद किया जा सकता है और फिर यह एक झूठी सुरक्षा है।"

— फ्लोरेंट्स त्लेसई

Answer 4

मुझे लगता है कि सार्वजनिक तरीकों में जोर का उपयोग करना और भी महत्वपूर्ण है, क्योंकि वहां आप इनपुट को नियंत्रित नहीं करते हैं और धारणा टूटने की संभावना अधिक हो सकती है।

परीक्षण इनपुट की स्थिति सभी सार्वजनिक और संरक्षित तरीकों से की जानी चाहिए। यदि इनपुट को सीधे किसी निजी विधि से पास किया जाता है, तो इसके इनपुट का परीक्षण निरर्थक हो सकता है।

परीक्षण उत्पादन की स्थिति (उदाहरण के लिए वस्तु स्थिति या रिटर्न वैल्यू! = शून्य) को आंतरिक तरीकों (जैसे निजी तरीकों) में किया जाना चाहिए। यदि अतिरिक्त गणना या आंतरिक स्थिति में परिवर्तन के बिना आउटपुट को एक निजी विधि से सार्वजनिक विधि के आउटपुट में सीधे पास किया जाता है, तो सार्वजनिक विधि की आउटपुट स्थितियों का परीक्षण करना निरर्थक हो सकता है।

मैं ओलेक्सी से सहमत हूं, हालांकि, यह अतिरेक पठनीयता बढ़ा सकता है और यह स्थिरता भी बढ़ा सकता है (यदि प्रत्यक्ष असाइनमेंट या वापसी अब भविष्य में मामला नहीं है)।

Comments

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

— 19'12

कथनों में (और कई मामलों में) लॉगिंग और थ्रोइंग अपवाद (या C-- में त्रुटि कोड) शामिल हो सकते हैं।

— डैनी वारोड

Answer 5

इस मुद्दे के बारे में भाषा-अज्ञेय होना कठिन है, क्योंकि इस बात का विवरण है कि कैसे जोर और 'उचित' त्रुटि / अपवाद को लागू किया जाता है, इसका उत्तर पर असर पड़ता है। यहाँ जावा और C ++ के मेरे ज्ञान के आधार पर, मेरी $ 0.02 है।

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

सार्वजनिक तौर-तरीकों में दावे करने से आम तौर पर बचना होता है। आप अभी भी जाँच कर रहे होंगे कि विधि अनुबंध का उल्लंघन नहीं किया गया है, लेकिन यदि ऐसा है तो आपको सार्थक संदेशों के साथ उपयुक्त-टाइप अपवादों को फेंकना चाहिए, जहां संभव हो, राज्य को वापस लाना आदि (क्या @rwong कॉल "पूर्ण" उचित त्रुटि उपचार उपचार ")।

सामान्यतया, आपको केवल अपने विकास / डिबगिंग में मदद करने के लिए अभिकथन का उपयोग करना चाहिए । आप यह नहीं मान सकते हैं कि जो कोई भी आपके एपीआई का उपयोग करता है, यहां तक ​​कि जब वे आपके कोड का उपयोग करते हैं तो भी सक्षम दावे होंगे। हालाँकि, कोड को दस्तावेज़ करने में उनका कुछ उपयोग होता है, फिर भी समान चीज़ों को दस्तावेज़ करने के लिए बेहतर तरीके हैं (अर्थात विधि दस्तावेज़, अपवाद)।

Answer 6

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

इसके अलावा सभी प्रोग्रामर परिपूर्ण नहीं हैं - फिर से, मुखर का मतलब है कि उन "स्लिप अप" में से एक बहुत दूर तक प्रचार नहीं करेगा।

इन असर (और मान्यताओं के बारे में अन्य जांच) के प्रभाव को कम मत समझो रखरखाव की लागत को कम करने में होगा।

Answer 7

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

यदि हर एक इकाई परीक्षण में एक या दो को छोड़कर, मुखर का एक ही सेट है, तो जब आप थोडा रिफ्लेक्टर करते हैं, तो सभी परीक्षण सटीक सटीक कारण के लिए विफल हो सकते हैं, बजाय आपको रिफ्लेक्टर के सही प्रभाव दिखाने के। आप एक ऐसी स्थिति में समाप्त हो सकते हैं जहां आप सभी परीक्षण चलाते हैं, वे सभी विफल हो जाते हैं क्योंकि प्रत्येक परीक्षण में एक ही दावे होते हैं, आप उस विफलता को ठीक करते हैं, फिर से परीक्षण चलाते हैं, वे किसी अन्य कारण से विफल होते हैं, आप उस विफलता को ठीक करते हैं। तब तक दोहराएं।

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

मैं यूनिट टेस्ट में डुप्लीकेट एसेर्स को शामिल करने की इच्छा को समझ सकता हूं, लेकिन यह वास्तव में ओवरकिल है। मैं अपने पहले टेस्ट प्रोजेक्ट के साथ उसी रास्ते से नीचे गया। मैं इससे दूर चला गया क्योंकि रखरखाव अकेले मुझे पागल कर रहा था।

Answer 8

हालांकि, सार्वजनिक तरीकों के लिए यूनिट परीक्षण का उपयोग किया जाता है।

यदि आपका परीक्षण ढांचा एक्सेसर्स के लिए अनुमति देता है, तो निजी विधियों का परीक्षण करना भी एक अच्छा विचार है (IMO)।

क्या कोई कोड गंध के रूप में बहुत अधिक अभिकथनों के बारे में सोच सकता है?

मैं करता हूँ। दावे ठीक हैं, लेकिन आपका पहला लक्ष्य इसे बनाना चाहिए ताकि परिदृश्य भी संभव न हो ; बस ऐसा नहीं होता है।

Answer 9

यह बुरा अभ्यास है।

आपको सार्वजनिक / निजी विधियों का परीक्षण नहीं करना चाहिए। आपको कक्षा को पूरी तरह से परखना चाहिए। बस सुनिश्चित करें कि आपके पास अच्छा कवरेज है।

यदि आप प्रत्येक विधि को अंगूठे के नियम के रूप में अलग-अलग परीक्षण करने के लिए (आदिम) तरीके से जाते हैं, तो आपको भविष्य में अपनी कक्षा को फिर से तैयार करने में बहुत मुश्किल होगी। और वह सबसे अच्छी चीजों में से एक है जो टीडीडी आपको करने में सक्षम बनाता है।

इसके अलावा, यह है दोहराव। इसके अलावा, यह बताता है कि कोड के लेखक को वास्तव में नहीं पता था कि वह क्या कर रहा है। और मजेदार बात यह है, आप करते हैं ।

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

Comments

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

— ओलेक्सी

इसके अलावा "यह पता चलता है कि कोड के लेखक को वास्तव में नहीं पता था कि वह क्या कर रहा था [...] आप करते हैं।" भविष्य के डेवलपर्स के रूप में एक विशेष विधि क्या करता है पर स्पष्ट नहीं हो सकता है। इस मामले में, मुखर के रूप में पूर्व और पोस्ट की स्थिति को कोड के एक टुकड़े को समझने में अमूल्य हो सकता है।

— ओलेक्सी

@ ओलेक्सी अच्छा परीक्षण वैध उपयोग परिदृश्यों के बारे में है, न कि हर छोटी से छोटी अप्रासंगिक विवरण के बारे में। निरर्थक दावे वास्तव में एक कोड गंध हैं क्योंकि अस्पष्ट इरादा है, और रक्षात्मक प्रोग्रामिंग का सिर्फ एक और बुरा उदाहरण है।

— यम मारकोविच