क्या आप काम में यूनिट परीक्षणों का उपयोग करते हैं? आपको उनसे क्या लाभ मिलता है? [बन्द है]

Question

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

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

Comments

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

— एस.लॉट

यह भी शायद गलत है, anecdotally, मैं अभी तक के लिए या एक कंपनी है कि कम से कम इकाई परीक्षण के कुछ स्तर नहीं था के साथ काम करने के लिए है

— jk।

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

— टॉबी

इस साइट के डेवलपर्स कितना यूनिट परीक्षण करते हैं?

— जेएफओ

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

— न्यूटोपियन

Answer 1

उनमें से कुछ मुझे सुझाव देते हैं कि यह आवश्यक नहीं है

खैर, सख्त अर्थों में वे सही हैं: परीक्षण, कोड समीक्षा, स्रोत नियंत्रण आदि भी कड़ाई से आवश्यक नहीं हैं। केवल यही कि बहुत कम समझदार डेवलपर लॉन्ग टर्म में इनके बिना काम करते हैं। हम में से अधिकांश ने सीखा है (अक्सर कठिन रास्ता, अपनी गलतियों से) क्यों ये सर्वोत्तम अभ्यास हैं।

और इसका बहुत कम लाभ है।

यह ज्यादातर मामलों में सच नहीं है। यही है, अगर हम उत्पादन सॉफ्टवेयर के बारे में बात कर रहे हैं जो उपयोग में माना जाता है - इस प्रकार रखरखाव में - आने वाले वर्षों के लिए।

उनका यह भी दावा है कि उत्पादन सॉफ्टवेयर के साथ केवल कुछ कंपनियां ही यूनिट-टेस्ट करती हैं।

यह सच हो सकता है (यद्यपि मेरे अनुभव में कम और कम), लेकिन इसका इकाई परीक्षण के मूल्य के बारे में कुछ नहीं कहना है । इस पुराने मजाक के विपरीत "गंदगी अच्छी है - 50 बिलियन मक्खियाँ गलत नहीं हो सकती हैं!" ;-)

क्या आपने अपने काम पर यूनिट-टेस्ट लागू किया और आपको इससे क्या मिला? (उदाहरण के लिए बेहतर कोड गुणवत्ता, लंबी अवधि में समय कम करना आदि)

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

Answer 2

मैं काम करता है, लेकिन नहीं (या कुछ)

मुझे प्राप्त होने वाले परीक्षण के मुख्य लाभ यह हैं कि रिफैक्टरिंग पूरी तरह से आसान है और यह प्रतिगमन (यानी, पहले से तय त्रुटियों का पुन: उत्पादन) देखा जाता है।

परीक्षण 'बिल्ड' के साथ रहता है: आप रनिंग टेस्ट के साथ सॉफ्टवेयर की जांच करते हैं, और आप तब तक जांच नहीं करते हैं जब तक कि सभी परीक्षण आपके संशोधन के साथ नहीं चल रहे हों।

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

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

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

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

Comments

नकारात्मक लगने के लिए खेद है, लेकिन मैं अभी भी 'कैसे एक चीज के रूप में प्राप्त करने के लिए' द्वारा जला दिया जाता है?)

— कीपला

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

— पीटर क्रुथोफ

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

— पेटर तोर्क

@keppla, काफी उचित, अगर टीम के साथी अपने सामान्य ज्ञान को खोने के स्तर के पक्षपाती हैं, तो तार्किक प्रमाण द्वारा उन्हें समझाने का कोई तरीका नहीं है :-( ऐसे मामले में, मजबूत प्रबंधन समर्थन के साथ आप अभी भी विचार को आगे बढ़ाने में सफल हो सकते हैं। , लेकिन इसके बिना, कोई उम्मीद नहीं है।

— Péter Török

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

— कीपला

Answer 3

मैं आपके सहयोगियों के साथ हूं, लेकिन केवल एक बिंदु तक।

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

def add(x, y)
  x + y
end

यह सुनिश्चित करने के लिए एक दर्जन परीक्षणों के साथ कि अतिरिक्त वास्तव में मनमाने ढंग से चुने गए उपयोग-मामलों के लिए काम करेगा। ओह ...

इकाई परीक्षण के पीछे सामान्य आधार है: यदि आपके कोड में कोई बग नहीं है, ऐसा इसलिए है क्योंकि आपने पर्याप्त परीक्षण नहीं किया है। अब, उचित इकाई परीक्षण कब लिखें। उत्तर:

1. जब आप परीक्षण कर रहे हैं
2. जब आप डिबगिंग कर रहे हैं
3. जैसा कि आप वास्तव में मुश्किल चीजें विकसित कर रहे हैं

चलो हर एक के माध्यम से चलते हैं, यह मानते हुए कि आप किसी तरह का वेब ऐप विकसित कर रहे हैं।

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

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

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

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

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

Comments

जैसा कि केंट बेक ने कहा: "सब कुछ का परीक्षण करें जो संभवतः टूट सकता है।"

— पेटर तोर्क

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

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

Answer 4

सभी कोड का परीक्षण किया जाना चाहिए। उसके बारे में कोई विकल्प नहीं है।

अनटाइड कोड बेकार है: यह कुछ भी करने के लिए भरोसा नहीं किया जा सकता है।

आप इकाई परीक्षण लिख सकते हैं या आप उच्च-स्तरीय एकीकरण परीक्षण या स्वीकृति परीक्षण लिखने की आशा कर सकते हैं।

यूनिट परीक्षणों को लिखना आसान है, डिबग करना आसान है, और प्रबंधन करना आसान है।

एकीकरण परीक्षण उन मान्यताओं पर आधारित हैं जो इकाइयां वास्तव में काम करती हैं। इकाई परीक्षणों के बिना, आप कैसे जानते हैं कि इकाईयां कैसे काम करती हैं? यदि आप व्यक्तिगत इकाइयों को वास्तव में काम करने के लिए एकीकृत नहीं जानते हैं तो आप एकीकरण परीक्षण को कैसे डिबग कर सकते हैं?

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

परीक्षण अनिवार्य है। सभी उच्च-स्तरीय परीक्षण वास्तव में काम करने वाली इकाइयों पर निर्भर करते हैं।

यह इकाई परीक्षण को एक तार्किक आवश्यकता बनाता है। और कोई विकल्प नहीं है।

Comments

कोई अन्य विकल्प नहीं है ... यदि आप गुणवत्ता की परवाह करते हैं। अधिकांश सॉफ़्टवेयर संगठन वास्तव में गुणवत्ता के बारे में परवाह नहीं करते हैं (अब तक कि वे टूटे जाने वाले सॉफ़्टवेयर को शिप करने से इनकार करते हैं)।

— जोएरी सेबट्रेट्स

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

— S.Lott

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

— जोएरी सेबर्चेस

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

— S.Lott

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

— मार्टिन बा

Answer 5

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

यह काफी सरल है: यदि आप यह प्रदर्शित नहीं कर सकते कि आपका कोड काम करता है (और परीक्षण के रूप में एक निष्पादन योग्य विनिर्देश से बेहतर तरीका क्या है?) तो यह काम नहीं करता है ।

यह मुझे देता है:

• मन की शांति: मेरा CI सर्वर मुझे अपना पूरा कोडबेस काम बताता है।
• मेरे कोड में सुधार करने की क्षमता: मैं अपने कोड का पुनर्गठन कर सकता हूं - इसे रीफैक्टर - यह जानकर कि पुनर्गठन के बाद मैंने कुछ भी नहीं तोड़ा है।

Comments

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

— रयान ब्रूनर

जब तक आपका पर्यावरण "अगर आप यह प्रदर्शित नहीं कर सकते कि आपका कोड काम नहीं करता है तो यह काम नहीं करता है।" : पी

— डेवि 8

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

— फ्रैंक

@ डेवी 8: किस मामले में आपको अधिक गंभीर समस्याएं हैं कि "यूनिट टेस्ट काम करते हैं?"।

— फ्रैंक शीयर जूल

Answer 6

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

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

मुझे आपके सहयोगियों पर संदेह है कि इसका उपयोग करने के खिलाफ सिफारिश करने वाले प्रोग्रामर नहीं हैं। यदि वे हैं, तो ठीक है हम कहते हैं कि बहुत से लोग नहीं हैं जिन्हें मैं मार्टिन फॉलर या केंट बेक जैसे लोगों से अधिक मूल्य देता हूं ;)।

अधिकांश सर्वोत्तम प्रथाओं की तरह, लाभ दीर्घकालिक हैं, आपको इसमें कुछ समय निवेश करने की आवश्यकता है। आप प्रक्रियात्मक कोड की एक लंबी स्क्रिप्ट लिख सकते हैं, लेकिन हम सभी जानते हैं कि आप चाहते हैं कि आपने इसे ऑब्जेक्ट-ओरिएंटेड शैली में लिखा हो, जब आपको 2 साल बाद इसे रिफैक्ट करने की आवश्यकता हो।

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

Answer 7

यूनिट-टेस्ट में यूनिट-टेस्ट फ्रेंडली भाषा, यूनिट-टेस्ट फ्रेंडली डिज़ाइन और यूनिट-टेस्ट फ्रेंडली समस्या की आवश्यकता होती है।

C ++, बहुपरत डिज़ाइन और GUI एक बुरा सपना होगा, और समस्या कवरेज भयावह होगी।

.NET, पुन: प्रयोज्य एकल-थ्रेड dll असेंबली, शुद्ध कम्प्यूटेशनल तर्क एक हवा होगी।

क्या यह इसके लायक है, मैं वास्तव में नहीं कह सकता।

क्या आप ज्यादा रिफलेक्टर करते हैं? क्या आपको अपने कोड में "बेवकूफ कीड़े" जैसे "बंद एक" बहुत दिखाई देते हैं?

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

Comments

बहुस्तरीय डिजाइन एक बुरा सपना क्यों होगा? तुल्यकालन अंक के लिए डिजाइन, और वहाँ परीक्षण।

— फ्रैंक शीयर

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

— कोडर

मैंने टेस्ट-संचालित मल्टीथ्रेडेड सामान लिखा है। यह सबसे निश्चित रूप से उल्लेखनीय है।

— फ्रैंक शीयर

बकवास, आप किसी भी भाषा में इकाई परीक्षण कर सकते हैं।

— जे.के.

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

— मौका

Answer 8

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

मैं थका देने वाली डमी परियोजनाओं में इकाई परीक्षणों में दब गया हूं, लेकिन मैं वास्तव में पूर्ण विकसित TDD / BDD के आसपास अपना सिर नहीं मिला है, और एक संरक्षक नहीं है जो इसके साथ मदद कर सकता है जो इसे ठीक से करने के लिए बहुत कठिन बनाता है।

Answer 9

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

यह उन चीजों को खोजने का एक शानदार तरीका है जो एक कोड समीक्षा में छूट जाते हैं।

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

सिस्टम-स्तरीय स्वचालन परीक्षणों के लिए 40+ मिनट और मैनुअल परीक्षण के लिए घंटों / दिनों के साथ तुलना करें। बेशक, यूनिट परीक्षण केवल ऐसा परीक्षण नहीं है जो आपको करना चाहिए, लेकिन एक महीन दानेदार कोड-स्तर पर वे बग ढूंढने में मदद कर सकते हैं और उन किनारे मामलों का परीक्षण कर सकते हैं जिन्हें सिस्टम / एकीकरण परीक्षण स्पर्श नहीं कर सकते। हमारे कोड को 75% से अधिक निर्णय कवरेज और 100% फ़ंक्शन कवरेज के साथ परीक्षण किया जाना चाहिए, जो कि यूनिट परीक्षणों के बिना प्राप्त करना बहुत कठिन होगा।

Answer 10

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

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

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

Answer 11

लागत: कोड को धीमा, लर्निंग कर्व, डेवलपर जड़ता

लाभ: आम तौर पर मैंने खुद को बेहतर कोड लिखते हुए पाया जब मैंने पहले परीक्षण किया - SOLID वार ...

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

Answer 12

मैं मौका मिलने पर काम पर कुछ यूनिट टेस्ट करता हूं, और मैं अपने सहयोगियों को भी ऐसा करने के लिए मनाने की कोशिश करता हूं।

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

Answer 13

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

इकाई परीक्षण के लिए मेरे दिशानिर्देश हैं:

1. हर शर्त का परीक्षण करें जो आप अपने कोड के लिए सोच सकते हैं, जिसमें खराब इनपुट, सीमाएं आदि शामिल हैं।
2. सभी मॉड्यूल के लिए सभी यूनिट टेस्ट को नियमित रूप से निष्पादित किया जाना चाहिए (यानी रात के निर्माण के हिस्से के रूप में)
3. यूनिट टेस्ट परिणाम की जाँच करें!
4. यदि कोई आपके कोड में बग ढूंढता है जो आपके परीक्षण से अतीत में मिला है, तो इसके लिए एक नया परीक्षण लिखें!

Answer 14

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

सबसे कठिन हिस्सा अच्छी इकाई परीक्षण लिख रहा है ।

यह आपके कोड के लिए एक अच्छा बेंचमार्क है।