क्या यूनिट परीक्षण नहीं लिखना उचित है क्योंकि वे बाद में टिप्पणी करने के लिए जाते हैं या क्योंकि एकीकरण परीक्षण अधिक मूल्यवान हैं?

Question

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

उनके बिंदुओं का योग करने के लिए:

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

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

Comments

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

— रॉबर्ट हार्वे

@ रोबर्ट हार्वे - सहमत - मुझे इन संपत्तियों की एक सूची देखने में दिलचस्पी होगी।

— जेफ लेविन

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

— जैक्सबी

संबं धत

— ल ं क

programmers.stackexchange.com/questions/199090/…

— रॉबर्ट हार्वे

Answer 1

मैं आपके दोस्त के साथ जाता हूं क्योंकि सभी अक्सर, यूनिट परीक्षण गलत चीजों का परीक्षण कर रहे हैं ।

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

मेरे सिर के ऊपर एक उदाहरण एक परीक्षण है जो कुछ साल पहले वर्डप्रेस में टक गया था। कार्यक्षमता का परीक्षण उन फ़िल्टर के इर्द-गिर्द घूमता है, जो एक दूसरे को कहते हैं, और परीक्षण इस बात की पुष्टि कर रहे थे कि कॉलबैक को फिर सही क्रम में बुलाया जाएगा। लेकिन (ए) के बजाय श्रृंखला को चलाने के लिए यह सत्यापित करने के लिए कि कॉलबैक को अपेक्षित क्रम में बुलाया जाता है, परीक्षण (बी) कुछ आंतरिक स्थिति को पढ़ने पर ध्यान केंद्रित करता है जो यकीनन शुरू होने से पहले उजागर नहीं होना चाहिए। इंटर्नल्स बदलें और (बी) लाल हो जाता है; जबकि (ए) केवल लाल हो जाता है यदि आंतरिक परिवर्तन ऐसा करते समय अपेक्षित परिणाम को तोड़ते हैं। (ख) मेरे विचार में स्पष्ट रूप से एक व्यर्थ परीक्षण था।

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

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

जैसे कि यह बेहतर या बदतर होने के बारे में नहीं है। यह सिर्फ इतना है कि एक गलत होने के लिए बहुत आसान है, और वास्तव में व्यवहार में बहुत बार गलत है।

Comments

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

— सिरका

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

— एंड्रेस एफ।

@DocBrown: वास्तव में नहीं। मेरा क्या मतलब है, यह अक्सर गलत हो जाता है कि ओपी के सहकर्मी ने इसे ज्यादातर मामलों में सही किया है - या कम से कम उन सभी मामलों में जो मैंने कभी यूनिट-टेस्ट की जुनूनी कंपनियों में चलाए हैं।

— डेनिस डे बर्नार्डी

@डेनिसडेबर्नेरी: मेरी बात यह है कि आपने जो कुछ भी लिखा है वह निश्चित रूप से अभ्यास के बहुत सारे ज्ञान के साथ सही है, लेकिन मुझे एक निष्कर्ष याद आ रहा है कि ओपी मामले का उनके सहयोगी के साथ क्या मतलब है, "एकीकरण के रूप में" के सुझाव के संदर्भ में बेहतर विकल्प ”।

— Doc Brown

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

— विन्सेंट सवार्ड

Answer 2

जब प्रमुख कोड परिवर्तन होते हैं, तो यूनिट परीक्षणों को पुन: प्रकाशित करने के बजाय टिप्पणी की जाती है।

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

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

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

Comments

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

— जेफ लेविन

+1 के लिए "आपको अपनी पूरी की गई परिभाषा पर काम करना होगा"। खूब कहा है!

— एंड्रेस एफ।

Answer 3

मुझे नहीं पता कि मैं आपके सहयोगी के तर्कों को स्वीकार करता हूं।

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

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

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

यदि आप सूक्ष्म और दार्शनिक प्राप्त करना चाहते हैं, तो कई महान संसाधन हैं:

• इयान बेकिंग का परीक्षण हानिकारक माना जाता है (परीक्षण पर्याप्त नहीं है। परीक्षण कोड को सुंदर नहीं बनाते हैं।)
• Dan Manges का बढ़ता हुआ कोड कवरेज हानिकारक हो सकता है (यदि आप उपयोगी कुछ भी कर रहे हैं तो मीट्रिक कवरेज का उपयोग करना आपको बताता नहीं है।)
• फिर यूनिट परीक्षण नहीं लिखने के लिए कोई अच्छा तर्क है? स्टैक ओवरफ्लो से [बंद] । (ओवर कॉन्फिडेंस, लागत की पहचान नहीं है, कपटी कीड़े नहीं ढूंढता, सुंदर कोड के लिए रिप्लेसमेंट नहीं [तरह तरह का Bicking], आदि ...)

Comments

उस लेख के लिए +1, ओपी मामले का एक बेहतर जवाब हो सकता है, जो हम यहां लिख सकते हैं

— Doc Brown

+1 अंक संख्या 1 के लिए आलस एक बहाना है। मैं पर्याप्त तनाव नहीं कर सकता कि कितना निराशाजनक है। मैं वहाँ गया था। हाल ही में, वास्तव में।

— ग्रेग बरगद

कारण 1 इकाई परीक्षणों की गलती नहीं है, लेकिन यह अभी भी इकाई परीक्षणों के खिलाफ एक कारण है।

— user253751

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

— जूल्स

Answer 4

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

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

Answer 5

यूनिट परीक्षणों में पुन: काम के बजाय टिप्पणी की जाती है।

जिस बिंदु पर कोड समीक्षा प्रक्रिया कहती है "गो यूनिट इकाइयाँ ठीक करें" और यह कोई समस्या नहीं है :-) यदि आपकी कोड समीक्षा प्रक्रिया प्रस्तुत कोड में इस तरह के बड़े दोष को नहीं पकड़ रही है, तो यह समस्या है।

Answer 6

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

मैं हमेशा रीफैक्टरिंग और कार्यक्षमता के परिवर्तन को अलग रखने की कोशिश करता हूं। जब मुझे दोनों करने की आवश्यकता होती है, तो मैं आमतौर पर पहले रिफैक्टरिंग करता हूं।

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

यह संभव है कि परिवर्तन जो कार्यक्षमता में परिवर्तन नहीं करते हैं, फिर भी त्रुटिपूर्ण इकाई परीक्षणों के कारण इकाई परीक्षण विफल हो जाते हैं। यदि आप समझते हैं कि आप जिस कोड को बदल रहे हैं, तो ऐसी इकाई परीक्षण विफलताओं का कारण आमतौर पर तुरंत स्पष्ट और तय करना आसान है।

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

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

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

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

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

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

Answer 7

एकीकरण परीक्षण यह जांचने के लिए किए जाते हैं कि क्या सिस्टम वैसा ही व्यवहार करता है जैसा कि माना जाता है, जिसमें हमेशा व्यापार मूल्य होता है। यूनिट परीक्षण हमेशा ऐसा नहीं करते हैं। उदाहरण के लिए, यूनिट परीक्षण मृत कोड का परीक्षण कर सकते हैं।

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

हर परीक्षण विधि अधूरी होगी। यहां तक ​​कि अगर आपको कुछ मीट्रिक द्वारा 100% कवरेज मिलता है, तो भी आप इनपुट डेटा के लगभग हर संभव सेट से नहीं गुजर रहे हैं। तो, नहीं लगता कि इकाई परीक्षण जादू हैं।

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

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

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

Answer 8

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

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

आपके मित्र द्वारा किए गए बिंदुओं का जिक्र:

1. यदि POJO जोड़ने से आपकी इकाई परीक्षण टूट जाते हैं तो वे संभवतः बहुत बुरी तरह से लिखे गए हैं। पीओजेओ आमतौर पर आपके द्वारा डोमेन के बारे में बात करने के लिए आप जिस भाषा का उपयोग कर रहे हैं, और जो समस्याएं आप हल कर रहे हैं, उन्हें स्पष्ट रूप से बदलने का मतलब है कि आपके संपूर्ण व्यावसायिक तर्क, और शायद प्रस्तुति कोड को बदलना होगा। आप उम्मीद नहीं कर सकते हैं कि आपके कार्यक्रम के उन हिस्सों को क्या भरोसा दिलाता है कि वे नहीं बदलते हैं ...

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

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

Answer 9

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

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

हालाँकि: पहली बार में परीक्षण लिखने के समय में एक (छोटी) लागत है।

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

Comments

+1 जो पूछे गए सवाल का ईमानदारी से जवाब देने का प्रयास करने के लिए।

— रबरडुक

इकाई परीक्षण की लागत निश्चित रूप से छोटी नहीं है। अच्छी इकाई परीक्षण आमतौर पर जितना वे परीक्षण करते हैं, उससे लिखने में अधिक समय लगता है। अधिकांश समय लाभ लागत से अधिक होता है।

— AK_

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

— gbjbaanb

यदि कोई परियोजना पर्याप्त रूप से छोटी है और उसे निरंतर रखरखाव / अपडेट की आवश्यकता नहीं है - अधिकांश विरासत प्रणाली परीक्षण के बिना लघु परियोजना के रूप में शुरू हुई हैं - और परीक्षण के बिना विकसित प्रणाली को बनाए रखने के लिए अधिक डेवलपर्स को काम पर रखने के साथ समाप्त होती हैं

— Fabio