यूनिट परीक्षण करते समय "यूनिट" क्या होना चाहिए?

Question

प्रोजेजिट पर आज मैं एक सबमिशन पर टिप्पणी धागा पढ़ रहा था, "Why Unit Testing Is A Waste of Time"।

मैं वास्तव में यह विषय में इतना के रूप में मैं एक comment बनाया साथ हूँ लेख के आधार के साथ संबंध नहीं कर रहा हूँ:

समस्या के स्टेम है कि सबसे अधिक व्यापार सॉफ्टवेयर में कोड की "इकाइयों" परियोजनाएं छोटी हैं।

इकाई के आकार को तब तक बदलें जब तक कि अब छोटा नहीं है? कौन कोड की इकाई को एक फ़ंक्शन या विधि के रूप में परिभाषित करता है !?

और

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

क्या हम कुछ वस्तुओं को मॉक करने के लिए बहुत अधिक समय बिताते हैं और कोड के एक छोटे टुकड़े का परीक्षण करते हैं और वास्तव में मूल्य के कुछ भी नहीं जोड़ते हैं?

यूनिट परीक्षण करते समय "यूनिट" क्या होना चाहिए? क्या कार्य स्तर परीक्षण बहुत दानेदार हैं?

Answer 1

यह Wikipedia उद्धृत करने के लिए तुच्छ लग सकता है, लेकिन मुझे लगता है यह बहुत संक्षिप्त और इस मामले में सही है:

एक इकाई एक आवेदन में सबसे छोटी परीक्षण योग्य हिस्सा है।

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

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

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

Answer 2

मैं कहूंगा कि एक इकाई काम का सबसे छोटा अर्थपूर्ण हिस्सा है जिसे छद्म कोड में अन्य चरणों से अलग किया जा सकता है।

उदाहरण के लिए, अगर आप की तरह

1. मिनट, अधिकतम, मंझला के लिए डाटासेट स्कैन करते हैं, कुछ डेटा की प्रक्रिया करने के लिए कदम की एक श्रृंखला करने के लिए कोशिश कर रहे हैं, इसका मतलब यह
2. एक हिस्टोग्राम उत्पन्न
3. एक remapping समारोह
4. remap डेटा
5. उत्पादन उत्पन्न डेटा

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

Answer 3

यदि आप मर्फी के कानून को ध्यान में रखते हैं तो कुछ भी मामूली नहीं है।

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

दुर्भाग्यवश, अक्सर स्थिरता की जांच करने का एकमात्र तरीका यह देखने के लिए कक्षा के विभिन्न तरीकों का आह्वान करना है कि वे विफल हैं या नहीं।

Answer 4

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

एक इकाई का पूरा बिंदु संगतता सुनिश्चित करने के लिए परीक्षण करता है (पूर्णांक को तोड़कर नहीं) और अनुमानित परिणाम सुनिश्चित करता है। किसी भी स्थान पर परीक्षण करने से सूचना का आदान-प्रदान आपके आवेदन को स्थिर करने में मदद करेगा।

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

Answer 5

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

Answer 6

मेरे लिए, एक "इकाई" कक्षा का कोई महत्वपूर्ण व्यवहार है, सड़क के नीचे 8-12 महीने में, मुझे याद नहीं है।

और अच्छी तरह से लिखित यूनिट परीक्षण (BDD सोचें) के साथ, मुझे यह नहीं करना होगा, क्योंकि मेरा परीक्षण मुझे वर्णन करेगा और सादे अंग्रेजी में कोड सत्यापित करेगा।

Answer 7

इकाई के आकार को तब तक बदलें जब तक कि अब छोटा नहीं है? कौन कोड की इकाई को एक फ़ंक्शन या विधि के रूप में परिभाषित करता है !?

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

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

मैं घटकों के बीच अनुबंधों का परीक्षण करने के लिए मैक्स का भी उपयोग करता हूं।

Answer 8

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

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

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

यहां ले जाने का मुद्दा यह है कि जिस इकाई को आप परीक्षण करना चाहते हैं वह वह इकाई है जो समझ में आता है। आप यूनिट परीक्षण को कार्यक्षमता सत्यापित करने और सत्यापित करने के लिए चाहते हैं; तो एक इकाई परीक्षण परीक्षण क्या है जिसे आप कार्यक्षमता के रूप में परिभाषित करते हैं। कार्यक्षमता की इकाई क्या है? यह परिभाषित करने के लिए आपकी व्यक्तिगत स्थिति पर निर्भर है।

Answer 9

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

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

तो, एक शब्द में: mu।