एक पेशेवर डेवलपर के रूप में, क्या इकाई परीक्षण नहीं लिखना स्वीकार्य है? [बन्द है]

Question

बस TDD / स्वचालित इकाई परीक्षण पर पेशेवरों और विपक्षों की सोच और समुदाय के दृष्टिकोण की तलाश है कि क्या पेशेवर डेवलपर्स के लिए सहायक इकाई परीक्षणों के बिना आवेदन लिखना स्वीकार्य है?

Comments

क्या आपने कोशिश की है, या आप बहाने नहीं ढूंढ रहे हैं?

फिर जवाब है "यह इस बात पर निर्भर करता है कि जो लोग आपको भुगतान करते हैं वे आपको करना चाहते हैं"।

@Florents "को" - ठीक है, नहीं, जरूरी नहीं है। एक काउंटर उदाहरण के लिए देखें कि 1994 में JWZ को नेटस्केप ब्राउज़र कैसे मिला। jwz.org/blog/2009/09/that-duct-tape-silliness । उनके पास उस के लिए समय नहीं था , और यूनिट परीक्षण आमतौर पर तब तक भुगतान नहीं करते हैं जब तक कि आप रखरखाव मोड तक नहीं पहुंच जाते।

भले ही यह स्वीकार्य हो या न हो , मेरा पेशेवर अनुभव रहा है कि इसे स्वीकार किया जाता है ।

— कार्सन63000

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

— SK-तर्क

Answer 1

क्या परीक्षण करने के लिए?

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

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

Answer 2

सिद्धांत

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

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

एक बार फिर, यह गारंटी नहीं देता है कि पूरी प्रणाली काम करेगी, लेकिन यह परीक्षण को सरल बनाती है।

टीडीडी स्वयं एक आवश्यकता नहीं है। यह एक डेवलपर को पहले जवाब देने के लिए मजबूर करके कोडिंग को सरल बनाता है, "मैं वास्तव में क्या कोड करने जा रहा हूं?"।

लागत

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

कहें कि आप अपने कोड में कोई त्रुटि करते हैं और उसी दिन पता लगा लेते हैं और उसे ठीक कर लेते हैं। लागत $ X है ।
मान लीजिए कि त्रुटि पूर्ववत बनी हुई है और साप्ताहिक आंतरिक बिल्ड में जाती है। सौभाग्य से, क्यूए ने इसका पता लगाया है, बग ट्रैकर में बग को उठाया है, यह मुद्दा 5 लोगों की बैठक पर 5 मिनट की चर्चा का विषय था, आदि, अंत में, आप इसे ठीक करते हैं। लागत सभी द्वारा खर्च की गई श्रमशक्ति का योग है, और इस मामले में $ 3 * X हो सकता है।
क्या होगा अगर त्रुटि बीटा परीक्षण और अधिक लोगों को शामिल करने के लिए गई थी? आइए कहते हैं, $ 10 * एक्स ।
यदि यह लंबे समय तक अनिर्धारित रहता है, तो 1,000 ग्राहक गए (उम्मीद है, एक मिलियन तक नहीं!), उनमें से 10 ने इसका पता लगाया, उन्होंने आपके सहायक कर्मचारियों के साथ चर्चा की, कुछ ने आपके बॉस को बुलाया, आपके साथियों ने इसे पुन: पेश करने का प्रयास किया , आदि, अंत में, बग आपके पास वापस आता है, और आप इसे ठीक करते हैं। कुल मिलाकर कितना? खैर से अधिक $ 50 * एक्स ।

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

प्रो की

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

कोन के

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

Comments

TDD एपीआई का अधिकार पाने के लिए है।

आप निम्नलिखित कहते हैं जैसे कि यह एक विरोधाभास था, लेकिन यह नहीं है: There's a common misconception that unit tests are for testing "units". Unit tests, likewise all other tests, test functionality.यूनिट परीक्षण बेशक इकाइयों का परीक्षण करने के लिए है ; जहां से नाम आता है।

— एंड्रेस एफ।

@AndresF। IMHO, इकाइयों को कोड की व्यवस्था करने का तरीका माना जाना चाहिए, लेकिन परीक्षण का विषय नहीं। इसी तरह "एक कप कॉफी पीना" का मतलब है कि एक कप में नहीं बल्कि एक कप में कॉफी पीना। :)

— बाइटबस्टर

Answer 3

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

Answer 4

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

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

Comments

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

— एंड्रेस एफ।

Answer 5

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

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

Answer 6

आप निश्चित रूप से "कोई परीक्षण नहीं" चाहते हैं। यदि आप इकाई परीक्षण लिखते हैं, तो आप कम से कम कुछ आश्वासन देते हैं कि आपका कोड आपके परीक्षणों से मेल खाता है (हालाँकि आपको यह सुनिश्चित करना होगा कि आपके परीक्षण आपके विनिर्देशन से मेल खाते हैं)।

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

Comments

किसी विनिर्देशन के पालन का आश्वासन देने के लिए यूनिट परीक्षण एकमात्र तरीका नहीं है। यह सबसे सख्त भी नहीं है।

— K.Steff

@ K.Steff आप पूरी तरह से सही हैं। मुझे उम्मीद है कि मेरे उत्तर को "आप सभी की आवश्यकता है यूनिट परीक्षण" के रूप में पढ़ना मुश्किल है।

— वेटाइन

Answer 7

मैं यहां एक अंग पर जा रहा हूं और कहता हूं कि यह ज्यादातर व्यक्तिपरक है और आपके लक्ष्यों पर निर्भर करता है। tl; dnr: यह करने के लिए अच्छा है, लेकिन इसके बारे में हठधर्मी होना सिर्फ और अधिक समस्याओं को जन्म देने वाला है।

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

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

यदि आप किसी ऐसी चीज़ पर काम कर रहे हैं, जहाँ कोई गड़बड़ी दुनिया का अंत नहीं होने वाली है, तो कम कवरेज शायद ठीक है। वित्तीय लेन - देन? बहुत सारे। यदि आपके पास मजबूत डेवलपर्स की एक टीम है जो कोडबेस को जानते हैं, एक साथ अच्छी तरह से काम करते हैं और कोई कारोबार नहीं है, तो आपको शायद कम कवरेज की आवश्यकता है। आदि।

तो यह शायद कुछ समारोह होने जा रहा है

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

ऐसी बहुत सी परिस्थितियाँ हैं जहाँ इकाई परीक्षण नहीं लिखना स्वीकार्य होगा। TDD अभी 'इन' है, लेकिन यह सिल्वर बुलेट नहीं है।

Answer 8

यह रखरखाव योग्य यूनिट टेस्ट लिखना पेशेवर है जो आपको समय और आँसू बचाएगा!

वहाँ एक है misconception that Unit test finds bugs। ठीक है कि बस सभी मामलों के लिए सच नहीं है। इकाई परीक्षण बग खोजने या प्रतिगमन का पता लगाने के बारे में नहीं है। यह परिभाषा के अनुसार है examine each unit of your code separately। लेकिन जब आपका आवेदन वास्तविक के लिए चलता है, तो उन सभी इकाइयों को एक साथ काम करना पड़ता है, और पूरे स्वतंत्र रूप से परीक्षण किए गए हिस्सों की तुलना में अधिक जटिल और सूक्ष्म होता है।

इस प्रकार, इकाई परीक्षण (टीडीडी प्रक्रिया के भीतर) का लक्ष्य सॉफ्टवेयर घटकों को मजबूती से डिजाइन करना है।

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

Answer 9

एक पेशेवर डेवलपर के रूप में, क्या इकाई परीक्षण नहीं लिखना स्वीकार्य है?

नहीं।

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

ये इकाई परीक्षण कितने पूर्ण होने चाहिए?

यहां लिटमस टेस्ट दिया गया है: यदि QA आपके कोड में बग का पता लगाता है, तो क्या आप अपने बॉस के लिए आपके उचित परिश्रम को साबित करने के लिए अपने यूनिट टेस्ट (s) का उपयोग करके सहज होंगे?

यदि आपका उत्तर 'नहीं' है, तो आपको एक बेहतर इकाई परीक्षण (या परीक्षण) तैयार करना चाहिए।
यदि आपका उत्तर 'हां' है, तो आपका कोड सत्यापन के लिए तैयार है।

एक पेशेवर डेवलपर के रूप में, क्या स्वचालित इकाई परीक्षण नहीं लिखना स्वीकार्य है ?

हाँ।

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

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