unit testing - यदि इकाई परीक्षण इतना महान है, तो अधिक कंपनियां क्यों नहीं कर रही हैं?




unit-testing (20)

मुझे इकाई परीक्षण याद आती है - यह सिर्फ जीवन को आसान बनाती है।

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

एक पर्याप्त कारण "सस्ता" (और / या, "बेहतर") हो सकता है: जो यूनिट परीक्षण के बारे में साबित करना उतना आसान नहीं है।

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

ऐसे कई डेवलपर्स हैं जो यूनिट परीक्षणों की दुनिया को नहीं सोचते हैं: जिनमें कुछ लोग सोचते हैं कि परीक्षण के अन्य रूप (जैसे स्वचालित एकीकरण / कार्यात्मक परीक्षण) सस्ता और अधिक मूल्यवान हो सकते हैं, उदाहरण के लिए क्या मैं एकमात्र देव हूं जो ' यूनिट परीक्षण की तरह टी?

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

मुझे इकाई परीक्षण याद आती है - यह सिर्फ जीवन को आसान बनाती है। लेकिन मुझे लगता है कि जब मैं एक नई नौकरी की तलाश करता हूं, यूनिट परीक्षण या तो कुछ ऐसा होता है जो कंपनियां भविष्य में "साथ जाने" या कुछ ऐसा नहीं करना चाहती हैं (ओह, यह थोड़ी देर के लिए आसपास है अभी व!)। मैं कहूंगा कि पिछले 2 वर्षों में मैंने देखा है कि नौकरी reqs के 60-75% यूनिट परीक्षण सूचीबद्ध नहीं है। मैं केवल एक या दो के बारे में सोच सकता हूं जिसमें यूनिट परीक्षण अनुभव एक आवश्यकता के रूप में था (मध्य-स्तर की डेवलपर स्थिति के लिए)।

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

संपादित करें: भले ही शीर्षक थोड़ा शैतान-वकील है, मैं खुद को एक इकाई परीक्षण समर्थक मानता हूं।


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

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

मुझे लगता है कि आपके प्रश्न का असली जवाब यह है: यूनिट परीक्षण वास्तव में कठिन है, और कंप्यूटर विज्ञान के छात्रों को इसके लिए प्रशिक्षित नहीं किया जाता है।

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

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

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

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


अधिकांश परीक्षण कुछ भी परीक्षण नहीं करते हैं।
आप एक फ़ाइलपेन () फ़ंक्शन और एक unittest लिखते हैं जो फ़ाइल में मौजूद नहीं है और फ़ाइल मौजूद होने पर सफल होता है। महान! अब आपने जांच की है कि यह बीआईजी 5 चीनी में फ़ाइल नाम के साथ काम करता है या नहीं? एनएफएस शेयर पर? एक यूएसबी कुंजी और यूएसी पर फ़ाइल के साथ Vista पर चालू?

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

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


इकाई परीक्षण के लिए दो चीजें बाधाएं हैं

  1. सबकुछ नया करना मुश्किल है
  2. सब कुछ जो मापने योग्य लाभ नहीं है, बुरा है।
  3. मनुष्य आलसी हैं। डेवलपर्स, वास्तव में।

मेरी कंपनी (> 5.000 एएमपी) इकाई परीक्षण में "वहां हैं", लेकिन टीडीडी करने या कोई बड़ा कोड कवरेज प्राप्त करने का कोई मौका नहीं है। इसे पूरा करना मुश्किल है।


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


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


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

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

संक्षेप में, हम टीडीडी में विश्वास नहीं करते हैं, लेकिन हम यूनिट टेस्ट करना चाहते हैं। हमारे पास ऐसा करने का अनुभव नहीं है, और हम इसे आसानी से नहीं ढूंढ सकते हैं।


ज्यादातर कंपनियां बेकार हैं। जाहिर है कि आप (या मैं) काम नहीं करते हैं।


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

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

तीसरा कारण आलस्य और / या सस्तापन है।


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


मुझे लगता है कि प्रोग्रामर को बस इसे करना शुरू करना है। शुरू करने के लिए कुछ सरल परीक्षण विकास के हिस्से के रूप में औचित्य साबित करना आसान है।

एक यूनिट टेस्ट की तरह कुछ तेजी से डीबगिंग बारी बारी से हमेशा आवश्यक है। बस सही इनपुट की व्यवस्था करना, डीबगर ब्रेकपॉइंट सेट करना, एप्लिकेशन लॉन्च करना आदि की तुलना में टेस्ट लॉन्च करना कितना तेज़ है, इसकी व्याख्या करें।

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


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

मुद्दा यह है कि, हम केवल कॉल करने के लिए योग्य हैं (जो यह नहीं कहना है कि हम सभी को इस विषय पर एक ही ज्ञान है)। इसके अलावा, भले ही आपकी टीम पॉलिसी के मामले में नहीं, यूनिट परीक्षण (या नाम-अपना-विधि-दिन-दिन) करें, इसका मतलब यह नहीं है कि आप इसे नहीं कर सकते हैं।

सच्चाई यह है कि, हम वास्तव में आरएनआई को वास्तविकता के बहुत अच्छे तरीके से नहीं करते हैं। प्रमाण के इस अनुचित / गैर-विशिष्ट मानक तक यूनिट परीक्षण क्यों किया जाता है मेरे बाहर है ...


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


मेरे अनुभव में, इसमें कुछ कारक शामिल हैं:

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

स्वाभाविक रूप से, अन्य कारक भी हैं, लेकिन वे वही हैं जो मैंने अभी तक चलाया है।


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


यदि आप परीक्षण पर सभी को बेचना चाहते हैं तो निम्न कार्य करें:

  1. परीक्षण का एक गुच्छा लिखें।
  2. उन अन्य डेवलपर्स को सूचित करें जो कोड बदलते हैं और आपके परीक्षण को विफल करते हैं।
  3. वे अपना कोड ठीक कर देंगे।
  4. अब आप उन विशेष बग के बिना रिलीज कर सकते हैं।

यहां तक ​​कि एक प्रबंधक भी इसे समझ सकता है।


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

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


यूनिट परीक्षण कोड विकास वर्कफ़्लो का एक स्वाभाविक हिस्सा होना चाहिए, जैसे संकलक है।

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

मेरा मानना ​​है कि यह आपके प्रश्न का उत्तर है "क्या गुम है और क्यों अधिक कंपनियां यूनिट परीक्षण नहीं कर रही हैं" । :-)


लोग आलसी हैं और जब मजबूर हो जाते हैं तो केवल परिवर्तन को अपनाते हैं।


वहाँ बहुत सारी कंपनियां हैं जो वास्तव में सर्वोत्तम प्रथाओं के अनुरूप कुछ भी नहीं करती हैं। कोई कोड समीक्षा नहीं, कोई इकाई परीक्षण नहीं, कोई परीक्षण योजना नहीं, कुछ भी नहीं, बस अपने पैंट की सीट से।

इसे एक सतत एकीकरण मंच का उपयोग करने और यूनिट परीक्षण विकसित करने का अवसर के रूप में लें! एक ही समय में अपने कोड की गुणवत्ता और स्थिरता को बढ़ाने और बढ़ाने वाली शक्तियों को प्रभावित करने का आसान तरीका

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







unit-testing