unit testing - क्या यूनिट परीक्षण के आरओआई का सख्त सबूत है?




unit-testing tdd (8)

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

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

कठिन सबूत कहां है कि आम लोगों को यह विश्वास दिलाएगा कि यूनिट परीक्षण प्रयास के लायक है?


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

क्यूं कर?

चुपचाप और निराशाजनक क्यों न करें। आपको इसे एक साथ करने की ज़रूरत नहीं है। आप इसे छोटे छोटे टुकड़ों में कर सकते हैं।

ढांचा सीखने में बहुत कम समय लगता है।

एक परीक्षण लिखना, सिर्फ एक, बहुत कम समय लेता है।

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

यह सब कुछ लेता है। किसी को भी यह जानने की जरूरत नहीं है कि आप इसे कर रहे हैं। बस कर दो।


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

अतिथि संपादकों का परिचय: टीडीडी-भयहीन प्रोग्रामिंग की कला [ link ]

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

तालिका 1. परीक्षण संचालित विकास के चयनित अनुभवजन्य अध्ययनों का सारांश: उद्योग प्रतिभागियों *

तालिका 2. टीडीडी के चयनित अनुभवजन्य अध्ययनों का सारांश: अकादमिक प्रतिभागियों *

बाहरी गुणवत्ता और उत्पादकता पर परीक्षण संचालित विकास के प्रभाव: एक मेटा-विश्लेषण [ link ]

सार:

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

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

अंत में, डेवलपर अनुभव और कार्य आकार का प्रभाव मॉडरेटर चर के रूप में किया गया था, और कार्य आकार और गुणवत्ता में सुधार की परिमाण के बीच एक सांख्यिकीय रूप से महत्वपूर्ण सकारात्मक सहसंबंध पाया गया था।


खैर, कुछ बड़ी कंपनियां हैं जिनके लिए आपको यूनिट परीक्षण का उपयोग करने की आवश्यकता होती है, लेकिन यदि आप एक छोटी कंपनी हैं तो बड़े लोगों की नकल क्यों करें?

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

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

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

कई कंपनियों में विकासशील सॉफ्टवेयर के एक अलग मॉडल में स्विच करने की कई विफलताओं और सफलता की कहानियां हैं।

जब भी मेरे पास लिखने के लिए कुछ नया था तब मैंने इसका इस्तेमाल शुरू कर दिया। एक पुरानी कहावत है जो मेरे लिए अंग्रेजी में अनुवाद करने के लिए कुछ मुश्किल हो जाती है लेकिन:

कुछ इतना आसान से शुरू करें कि आप ध्यान नहीं देते कि आप इसे करते हैं। मैराथन के लिए प्रशिक्षण करते समय, 9 मीटर चलकर शुरू करें और 1 मीटर चलाएं, दोहराएं।


मेरे पास इसके लिए डेटा पॉइंट्स का एक सेट है - एक अनुभव से जिसने मुझे यूनिट परीक्षणों पर बेचा।

कई चांद पहले मैं एक बड़े स्नातक थे जो एक बड़ी वीबी 6 परियोजना पर काम कर रहे थे और उन्हें संग्रहीत प्रक्रिया कोड का एक बड़ा निकाय लिखने का अवसर मिला। उपप्रणाली में मैं इसे पूरे कोड बेस के 1/4 के बारे में लिख रहा था - लगभग 50,000 या उससे अधिक के लगभग 13,000 LOC।

मैंने संग्रहित प्रक्रियाओं के लिए यूनिट परीक्षणों का एक सेट लिखा लेकिन यूनिट परीक्षण वीबी 6 यूआई कोड तर्कसंगत रोबोट जैसे उपकरणों के बिना वास्तव में व्यवहार्य नहीं है; कम से कम यह वापस नहीं था।

टुकड़े पर क्यूए के आंकड़े थे कि पूरे उपप्रणाली पर लगभग 40 या 50 दोष उठाए गए थे, जिनमें से दो संग्रहित प्रक्रियाओं से उत्पन्न हुए थे। कोड प्रति बनाम 6,500 लाइन प्रति 1000-1,200 या पूरे टुकड़े में यह एक दोष है । ध्यान रखें कि वीबी 6 कोड के बारे में 2/3 त्रुटि प्रक्रियाओं और लॉगिंग के लिए बॉयलरप्लेट कोड था, जो सभी प्रक्रियाओं में समान था।

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


यदि आप यूनिट परीक्षण के खिलाफ साक्ष्य में रुचि रखते हैं तो यहां एक अच्छी तरह से शोध किया गया है और लेख लिखा है:

अधिकांश ओ यूनिट परीक्षण जेम्स ओ कोप्लिन द्वारा अपशिष्ट क्यों है (दुबला और चुस्त गुरु)


यहां एक व्यक्ति के भीतर से अपनी कंपनी को बदलने वाले लड़के का एक शानदार और मनोरंजक पठन है। यह टीडीडी तक ही सीमित नहीं है। http://jamesshore.com/Change-Diary/ ध्यान दें कि उन्होंने कुछ समय के लिए "बीन काउंटर" को राजी नहीं किया और इसके बजाय "गुरिल्ला रणनीति" की।


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

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

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

क्या यह बीन काउंटर का व्यवसाय यह निर्धारित करने के लिए है कि तकनीकी लोगों को कैसे काम करना चाहिए? क्या वे सभी मामलों में सबसे सस्ता उपकरण उपलब्ध करा रहे हैं क्योंकि उनका मानना ​​है कि आपको अधिक महंगे लोगों की आवश्यकता नहीं है?

यह तर्क या तो ट्रस्ट (चुस्त टीमों के मौलिक मूल्यों में से एक) के आधार पर जीता जाता है या विजेता पार्टी की भूमिका शक्ति के आधार पर खो जाता है। भले ही टीडीडी-समर्थक भूमिका शक्ति के आधार पर जीतते हैं, मैं इसे खोने के रूप में गिनता हूं।


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

[संपादित करें] टीडीडी को गोद लेने के बाद प्रारंभिक विकास समय में विशेष रूप से टीडीडी के संदर्भ में दो पेपर और 15-35% की वृद्धि दिखाएं, लेकिन पूर्व-रिलीज दोषों में 40-90% की कमी। यदि आप पूर्ण पाठ संस्करणों पर नहीं पहुंच पा रहे हैं, तो मैं यह देखने के लिए Google विद्वान का उपयोग करने का सुझाव देता हूं कि क्या आप सार्वजनिक रूप से उपलब्ध संस्करण ढूंढ सकते हैं या नहीं।





tdd