यूनिट परीक्षण कितना अतिरिक्त समय लेता है?

Question

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

इस तरह के एक अध्ययन मौजूद है? क्या कोई अनुभव से टिप्पणी कर सकता है?

Answer 1

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

मामले के अध्ययन माइक्रोसॉफ्ट पर तीन विकास टीमों और एक आईबीएम में है कि TDD को अपनाया है के साथ आयोजित की गई। मामले के अध्ययन के परिणाम कि चार उत्पादों की रिलीज दोष घनत्व समान परियोजनाओं कि TDD अभ्यास का उपयोग नहीं किया करने के लिए 40% और 90% सापेक्ष के बीच की कमी हुई संकेत मिलता है। आत्मगत, टीमों के बाद अपनाने TDD प्रारंभिक विकास समय में एक 15-35% वृद्धि का अनुभव किया। Source.

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

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

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

Answer 2

मैं एक अध्ययन पर भरोसा नहीं होगा आपको बताने के लिए, आप बस इसे अपने आप को काम कर सकते हैं।

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

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

Answer 3

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

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

Answer 4

मामलों के सभी राज्य, सभी टीमों में यह अधिकार होना चाहिए:

TimeOf(Coding+Testing) < TimeOf(CodingWithoutTesting) 

यह बिल्कुल भी अतिरिक्त समय लगेगा should't। या यह बेकार हो जाएगा।

Answer 5

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

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

मैं इन सुझावों को बनाना होगा:

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

• यूनिट परीक्षण ढांचे (एनयूनीट, एक्सयूनीट इत्यादि) का मूल्यांकन करना शुरू करें, और मॉकिंग फ्रेमवर्क (राइनो मोक्स, मोक इत्यादि) का मूल्यांकन करना शुरू करें, और उन्हें मानकीकृत करने के लिए चुनने वाले लोगों को चुनें। सबसे लोकप्रिय शायद नुनीट और राइनो मोक्स हैं, लेकिन मैंने xUnit और Moq चुना है।

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

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

आशा है कि इससे मदद मिलती है!

Answer 6

मुझे अनुमान लगाने में सक्षम होना चाहिए कि आवंटित करने के लिए कितना अतिरिक्त समय है।

यह मूर्खतापूर्ण है। कोई अतिरिक्त समय नहीं है।

यहां आप क्या करते हैं। अपना मौजूदा परीक्षण बजट लें। परियोजना के अंत में 40% विकास प्रयास।

इस परीक्षण के अधिकांश प्रयासों को इकाई परीक्षण के रूप में परियोजना के जीवन के माध्यम से फैलाएं। कुल प्रयास का 30% इसे कॉल करें, हर जगह आवंटित।

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

कोई "अतिरिक्त" नहीं है। आपको वैसे भी परीक्षण करना है। आप परियोजना के दौरान या तो प्रथम श्रेणी के सॉफ्टवेयर के रूप में ऐसा कर सकते हैं, या आप खराब काम करने वाले प्रोजेक्ट के अंत में घूम सकते हैं।

---

टीडीडी की "लागत" सर्वोत्तम है - एक व्यक्तिपरक प्रभाव। ध्यान से उत्कृष्ट अध्ययन सारांश पढ़ें। "विषयपरक, टीमों ने टीडीडी को अपनाने के बाद प्रारंभिक विकास के समय में 15-35% की वृद्धि का अनुभव किया"। [जोर जोड़ा गया।]

वास्तव में टीडीडी के लिए शून्य लागत है। टीडीडी बस समय बचाता है।

यह अन्य तरीकों से सॉफ्टवेयर बनाने के लिए टीडीडी करने के लिए बहुत महंगा है।

क्यों?

1. आपको वैसे भी परीक्षण करना होगा। चूंकि आपको परीक्षण करना है, इसलिए आप परीक्षण के चारों ओर अपने सभी विकास को चलाकर परीक्षण के लिए भी योजना बना सकते हैं।

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

3. आपको वैसे भी परीक्षण करना होगा। यह कोड या तो कोड या उसके बाद टेस्ट कोड है। आप परीक्षण की लागत से बच नहीं सकते हैं। चूंकि आप बच नहीं सकते हैं, पहले इसे करें।

4. यह विचार कि टीडीडी में "अतिरिक्त" या "वृद्धिशील" लागत पागल है। यहां तक ​​कि http://www.springerlink.com/content/q91566748q234325/ जैसे एक अच्छी तरह से प्रलेखित अध्ययन भी नहीं कर सकते - असल में - की तुलना करें प्रोजेक्ट दो तरीकों से किया गया है। "अतिरिक्त विकास समय" का विचार वास्तव में मापा नहीं जा सकता है। यही कारण है कि यह एक "व्यक्तिपरक प्रभाव" है। और वे इसके बारे में बस गलत हैं।

जब आप प्रोग्रामर पूछना - जो TDD के लिए नए हैं - अगर TDD उन्हें धीमा, वे इसके बारे में के बारे में झूठ बोलते हैं।

हां। वे झूठ बोलते हैं।

वन। आपने उन्हें बदल दिया। परिवर्तन खराब है। हर कोई जानता है कि। वे यह नहीं कह सकते कि यह आसान था, क्योंकि यह "अलग" था।

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

तीन। अधिकांश प्रोग्रामर (और प्रबंधक) सोचते हैं कि "वास्तविक" कोड और "परीक्षण" कोड के बीच एक अंतर है। टीडीडी को "असली" कोड प्राप्त करने में अधिक समय लगता है क्योंकि आप अपना "आगे" कोड कर रहे समय के सामने खर्च करते हैं।

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

परीक्षा कोड लिखने का समय प्रभावी ढंग से - वास्तविक कोड के डिजाइन से लिया गया समय है। "पेपर" डिज़ाइन बनाने के बजाय, आप परीक्षण मामलों के रूप में एक काम कर रहे, रहने वाले डिजाइन बना रहे हैं।

टीडीडी समय बचाता है।

जो लोग कहते हैं कि अन्यथा परिवर्तन का विरोध कर रहे हैं और/या गलत होने और/या वास्तविक कोड और परीक्षण कोड के बीच झूठी भेद करने से प्रबंधन की रक्षा करने की कोशिश कर रहे हैं। सभी चीजें जो गलत हैं।