TDD क्यों काम करता है? [बन्द है]

Question

टेस्ट-संचालित विकास (टीडीडी) इन दिनों बड़ा है। मैं अक्सर इसे प्रोग्रामर एसई और अन्य स्थानों में समस्याओं की एक विस्तृत श्रृंखला के समाधान के रूप में देखता हूं। मुझे आश्चर्य है कि यह क्यों काम करता है।

इंजीनियरिंग के दृष्टिकोण से, यह मुझे दो कारणों से याद है:

1. "पास होने तक टेस्ट + रिफ्लेक्टर लिखो" दृष्टिकोण अविश्वसनीय रूप से इंजीनियरिंग विरोधी है। अगर सिविल इंजीनियरों ने अपनी कारों के लिए पुल निर्माण, या कार डिजाइनरों के लिए उस दृष्टिकोण का उपयोग किया, उदाहरण के लिए, वे अपने पुलों या कारों को बहुत अधिक लागत पर फिर से तैयार करेंगे, और परिणाम बिना किसी सोचे-समझे वास्तुकला के साथ एक पैच-अप गड़बड़ हो जाएगा। । "पास तक रिफ्लेक्टर" दिशानिर्देश को अक्सर वास्तुशिल्प डिजाइन को भूलने के लिए एक जनादेश के रूप में लिया जाता है और परीक्षण के अनुपालन के लिए जो कुछ भी आवश्यक होता है; दूसरे शब्दों में, उपयोगकर्ता के बजाय परीक्षण, आवश्यकता सेट करता है। इस स्थिति में, हम परिणामों में अच्छे "यूटिलिटीज" की गारंटी कैसे दे सकते हैं, अर्थात एक अंतिम परिणाम जो न केवल सही है, बल्कि एक्स्टेंसिबल, मजबूत, उपयोग करने में आसान, विश्वसनीय, सुरक्षित, सुरक्षित आदि है? यह वही है जो आमतौर पर वास्तुकला करता है।
2. परीक्षण यह गारंटी नहीं दे सकता है कि एक प्रणाली काम करती है; यह केवल यह दिखा सकता है कि यह नहीं है। दूसरे शब्दों में, परीक्षण आपको दिखा सकता है कि एक प्रणाली में दोष होते हैं यदि यह एक परीक्षण में विफल रहता है, लेकिन एक प्रणाली जो सभी परीक्षणों को पारित करती है, वह एक प्रणाली की तुलना में सुरक्षित नहीं है जो उन्हें विफल करती है। टेस्ट कवरेज, परीक्षण गुणवत्ता और अन्य कारक यहां महत्वपूर्ण हैं। झूठी "सुरक्षित" हरे रंग की भावनाएं जो कई लोगों को उत्पन्न करती हैं, सिविल और एयरोस्पेस उद्योगों में बेहद खतरनाक बताई गई हैं, क्योंकि यह "सिस्टम ठीक है" के रूप में परस्पर जुड़ा हो सकता है, जब यह वास्तव में इसका मतलब है कि "सिस्टम उतना ही अच्छा है हमारी परीक्षण रणनीति के रूप में "। अक्सर, परीक्षण रणनीति की जाँच नहीं की जाती है। या, परीक्षणों का परीक्षण कौन करता है?

सारांश में, मैं "परीक्षण" बिट की तुलना में TDD में "संचालित" बिट के बारे में अधिक चिंतित हूं। परीक्षण पूरी तरह से ठीक है; मुझे जो नहीं मिल रहा है वह यह करके डिज़ाइन को चला रहा है।

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

Comments

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

— लार्स विर्जेनियस

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

— ६५०२

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

— मचल

@ केसरगॉन, आप इस सवाल में भी दिलचस्प हो सकते हैं जो मैंने कुछ समय पहले एसओ से पूछा था ... काफी टीडीडी नहीं, लेकिन संबंधित ... कुछ बहुत ही ज्ञानवर्धक जवाब।

— एवीडी

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

Answer 1

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

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

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

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

वे सभी चीजें हैं जो आप टीडीडी के साथ रख सकते हैं।

और वास्तव में, परीक्षण कोई गारंटी नहीं है। कार्यक्रम दुर्घटनाग्रस्त हो जाता है, कारें टूट जाती हैं, और हवा चलने पर इमारतें मज़ेदार काम करने लगती हैं। लेकिन ... 'सुरक्षा' एक बूलियन प्रश्न नहीं है। यहां तक ​​कि जब आप कभी भी सब कुछ शामिल नहीं कर सकते हैं, तो कवर करने में सक्षम होना - कहना - 99% की स्थिति केवल 50% को कवर करने से बेहतर है। परीक्षण नहीं है और फिर यह पता लगाना कि स्टील अच्छी तरह से नहीं सुलझा है और भंगुर है और एक हथौड़ा की पहली स्मैक पर टूट जाता है जब आप बस अपना मुख्य ढांचा डालते हैं तो यह पैसे का एक सामान्य अपशिष्ट होता है। ऐसी अन्य चिंताएं हैं जो अभी भी इमारत को चोट पहुंचा सकती हैं, यह आसानी से रोके जाने योग्य दोष को अपने डिजाइन को नीचे लाने की अनुमति देने के लिए किसी भी कम बेवकूफ नहीं बनाती है।

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

Comments

विनिर्माण में परीक्षण कहां होता है, इसके बारे में बात करने के लिए +1। महान बिंदु।

— एडम लेअर

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

— सेसरगॉन

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

— इंका

+1: सॉफ्टवेयर विशुद्ध रूप से डिजाइन है। प्रश्न में सेतु सादृश्य पूरी तरह से गलत है। टीडीडी पूरी तरह से इकाई परीक्षण के बाहर लागू होता है। डिजाइन के सभी स्तरों पर परीक्षण-चालित डिजाइन लागू होता है।

— एस.लॉट

@ केसरगॉन: नहीं, TDD परीक्षण द्वारा विकास चला रहा है । यह डिजाइन को चलाने के लिए अलग है। डिज़ाइन यह निर्धारित करता है कि आप सिस्टम का उपयोग कैसे करेंगे, और इस प्रकार आपको उस व्यवहार को दोहराने के लिए किन परीक्षणों को लागू करना होगा। उन परीक्षणों को लागू करने से अक्सर आपको डिजाइन को परिष्कृत करने में मदद मिलती है , हालांकि।

— डेवॉर्ड

Answer 2

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

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

पीटर नॉरविग ने कोडर्स एट वर्क बुक में TDD पर अपने विचार को स्पष्ट किया।

सीबिल: ड्राइव डिजाइन के परीक्षणों का उपयोग करने के विचार के बारे में क्या?

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

Comments

अब, यदि आप इन तथ्यों को टीडीडी के लोगों और सलाहकारों को बताते हैं, तो आपको जो उत्तर मिलेगा, वह होगाwell, you haven't done TDD right!

— नवानेथ केएन

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

— एंडी

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

— न्यूटॉपियन

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

— डंक

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

— जियोर्जियो

Answer 3

निम्नलिखित कारणों से मेरे लिए परीक्षण संचालित डिजाइन काम करता है:

यह विनिर्देश का एक रननीय रूप है।

इसका मतलब है कि आप परीक्षण मामलों से देख सकते हैं:

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

आप पहले बाहर से दृश्य लिखें।

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

यह आमतौर पर क्लीनर कोड के परिणामस्वरूप होगा जिसमें कम व्याख्यात्मक प्रलेखन की आवश्यकता होती है।

आप तेजी से काम करें

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

इसका मतलब है कि आप बता सकते हैं कि काम करना आवश्यक है या नहीं (क्या यह एक परीक्षा पास करने में मदद करता है) आपको कम करने की आवश्यकता समाप्त हो जाती है।

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

हाल के एक अध्ययन

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

Comments

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

— एडवर्ड स्ट्रेंज

यह स्वीकृत उत्तर होना चाहिए।

— निंग

Answer 4

सॉफ्टवेयर बनाने की प्रक्रिया कोड लिखने की प्रक्रिया नहीं है। कोई भी सॉफ्टवेयर परियोजना पहले 'व्यापक दायरे' की योजना के बिना शुरू नहीं होनी चाहिए। जैसे नदी के दो किनारों को पाटने की परियोजना को पहले इस तरह की योजना की जरूरत है।

TDD दृष्टिकोण इकाई परीक्षण से संबंधित है (ज्यादातर) - कम से कम यह है कि लोग इसके बारे में कैसे सोचते हैं - जो सॉफ्टवेयर कोड के सबसे निम्न-स्तरीय बिट्स का निर्माण कर रहा है। जब सभी विशेषताओं और व्यवहारों को पहले से ही परिभाषित किया गया है और हम वास्तव में जानते हैं कि हम क्या हासिल करना चाहते हैं।

संरचनात्मक इंजीनियरिंग में यह इस तरह दिखता है:

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

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

देखें V-Model: http://en.wikipedia.org/wiki/V-Model_%28software_development%2929

आइए देखें कि यह पुल के लिए कैसे काम करेगा:

1. एक स्थानीय सरकार एक पुल बनाने वाली कंपनी से कहती है: "हमें इन दो बिंदुओं को जोड़ने के लिए एक पुल की आवश्यकता है। पुल को प्रति घंटे n की मात्रा में यातायात की अनुमति देने और 21 दिसंबर 2012 को तैयार रहने की आवश्यकता है" - यह एक परिभाषा है स्वीकृति परीक्षण। कंपनी को (या किसी भी) धन की पूरी राशि नहीं मिलेगी, यदि वे उस परीक्षा को पास नहीं कर सकते हैं।

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

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

Comments

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

— सीजरगॉन

@ केसरगॉन: टीडीडी एकीकरण परीक्षणों के लिए भी बहुत अच्छा काम करता है।

— सेवंसेकैट

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

— मचल

@ कर्क: और स्वीकृति परीक्षणों के लिए भी! आपको पहले से पता होना चाहिए कि क्लाइंट द्वारा स्वीकार किए जाने वाले आपके काम के लिए क्या आवश्यक है।

— मचल

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

— Mchl

Answer 5

मेरे दिमाग में TDD काम करता है क्योंकि

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

विशेष रूप से आपके द्वारा उठाए गए बिंदुओं पर

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

Comments

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

— एंडी

Answer 6

टी एल; डॉ

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

कोड डिजाइन है

पीपीपी के अध्याय 7 में "अंकल बॉब" इस मुद्दे पर सीधे बात करता है। अध्याय के बहुत पहले, वह जैक रीव्स द्वारा एक उत्कृष्ट लेख का संदर्भ देता है जिसमें वह प्रस्तावित करता है कि कोड डिजाइन है (लिंक विषय पर अपने सभी तीन लेखों को इकट्ठा करने वाले पृष्ठ पर जाता है)।

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

विशिष्टता के रूप में टीडीडी

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

कार्यक्षमता के लिए टेस्ट लिखें

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

public class PersonTest:Test
{
   [Test]
   TestNameProperty()
   {
      var person=new Person();
      person.Name="John Doe";
      Assert.AreEqual("John Doe", person.Name);
   }
}

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

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

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

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

Comments

कीड़े को पकड़ने वाले लाल परीक्षणों का मूल्य सामान्य रूप से इकाई परीक्षण का एक गुण है, विशेष रूप से टीडीडी का नहीं।

— रॉबर्ट हार्वे

तुम उस बिंदु पर सही हो। लेकिन मुझे लगता है कि पोस्ट-हॉक यूनिट परीक्षण के साथ कवर किया गया विशिष्ट बग की संभावना कम है।

— माइकल ब्राउन

क्या आप कुछ सबूत, डेटा या ठोस विश्लेषण के साथ दावा करने का समर्थन कर सकते हैं?

— सीजरगॉन

@ CesarGon , एक छोटे से प्रोजेक्ट पर काम करने वाले प्रोग्रामर्स के अनुसार, इस अध्ययन से पता चलता है कि TDD का उपयोग करने वाले डेवलपर्स, परीक्षण के बाद की तुलना में बेहतर परीक्षण कवरेज के साथ कोड का उत्पादन करते हैं, जो वास्तव में परीक्षण के बाद (92% -98% बनाम 80% -90%) है और परिणामस्वरूप अधिक पकड़ विकास के दौरान दोष (TDD का उपयोग करके उत्पादित कोड में पाए जाने वाले 18% कम दोष)।

— जूल्स

Answer 7

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

आपको ऐसा कोई भी नहीं मिलेगा जो नापसंद हो या TDD से प्रभावित न हो जो कहता है कि टेस्ट समय और प्रयास की बर्बादी है। हालांकि परीक्षण अनुप्रयोगों को साबित नहीं करते हैं, वे त्रुटियों को खोजने में काफी सहायक होते हैं।

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

इसलिए, टीडीडी और नॉट-टीडीडी के बीच का अंतर यह नहीं है कि परीक्षण किए जा रहे हैं। अंतर तब होता है जब परीक्षण लिखे जाते हैं। TDD परीक्षणों में सॉफ्टवेयर से पहले लिखा जाता है। सॉफ्टवेयर के साथ या कॉन्सर्ट में टीडीडी टेस्ट नहीं लिखे जाते हैं।

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

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

टीडीडी का लक्ष्य इस "परिपत्र तर्क" को तोड़ना है और सॉफ्टवेयर का परीक्षण करने वाले परीक्षणों के लिए आधार प्रदान करना है जो सॉफ्टवेयर ही नहीं है। परीक्षण उस व्यवहार को लक्षित करने के लिए लिखे गए हैं जो "ग्राहक" चाहता है। फिर सॉफ्टवेयर को उन परीक्षणों को पास करने के लिए लिखा जाता है।

TDD समाधान का एक हिस्सा है, हालांकि इस समस्या को हल करने के लिए। यह एकमात्र कदम नहीं है जो आप बनाते हैं। अन्य चीजें जो आपको करने की ज़रूरत है, सुनिश्चित करें कि अधिक ग्राहक प्रतिक्रिया है और अधिक बार।

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

Comments

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

— सीजरगॉन

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

— एडवर्ड स्ट्रेंज

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

— सीजरगॉन

नहीं। हमारे बिल्ड स्वचालित हैं। वे परिवर्तनों से ट्रिगर हुए हैं। जैसा कि मैंने कहा, टीडीडी समाधान का एक हिस्सा है।

— एडवर्ड स्ट्रेंज

Answer 8

पहले डिजाइन

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

लेकिन जल्दी परीक्षण करें

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

टेस्ट और डिजाइन ... एक और एक ही

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

फिर शो कौन चलाता है?

टीडीडी में यहां संचालित बस का मतलब है कि आपके परीक्षण आपके डिजाइन को इतनी मजबूती से प्रभावित करते हैं कि कोई महसूस कर सकता है कि वे वास्तव में इसे चला रहे हैं। हालाँकि यह उस पर रुक जाता है, और यहाँ मैं आपकी चिंताओं को समझता हूँ, यह थोड़ा डरावना है ... शो को कौन चलाता है?

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

जब तक परीक्षण ठोस होते हैं तब तक ठोस

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

हाँ, लेकिन अगर मैं अपने पुल वें के साथ ...

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

यदि इसका sooo अच्छा है तो यह हमेशा कैसे काम नहीं करता है?

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

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

टो इन टीमों TDD जाने के लिए रास्ता नहीं हो सकता है।

Answer 9

TDD के साथ आप ऐसे कोड नहीं लिखते हैं जो परीक्षण के लिए आसान या त्वरित नहीं है। यह एक छोटी सी बात की तरह लग सकता है, लेकिन यह किसी परियोजना पर गहरा असर डाल सकता है क्योंकि यह प्रभावित करता है कि रिफ्लेक्टर, परीक्षण करना, परीक्षण के साथ बग को पुन: उत्पन्न करना और फिक्स सत्यापित करना कितना आसान है।

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

Comments

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

— मर्फ़

@ मर्फ़ येह TDD आपको ईमानदार रखने में मदद करता है :)

— Alb

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

— Murph

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

— एडम लेअर

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

— मर्फ़

Answer 10

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

1) मेरा पहला कदम यह है कि, यह (प्राथमिक रूप से) TDD के कारण कोड में "बेहतर गुणवत्ता" को जोड़ने के कारण नहीं है (जैसे कि), यह TDD की तरह अधिक है जो खराब भागों और आदतों को बाहर निकालने में मदद करता है, और इसलिए अप्रत्यक्ष रूप से गुणवत्ता में वृद्धि करता है।

मैं यह भी वकालत करूंगा कि यह स्वयं परीक्षण नहीं है - यह उन परीक्षणों को लिखने की प्रक्रिया है । खराब कोड के लिए परीक्षण लिखना कठिन है, और इसके विपरीत। और इसे प्रोग्रामिंग करते समय सिर के पीछे रखने से बहुत से खराब कोड खत्म हो जाते हैं।

2) एक और दृष्टिकोण (यह दार्शनिक हो रहा है) गुरु की मानसिक आदतों का अनुसरण कर रहा है। आप उसकी "बाहरी आदतों" (जैसे, एक लंबी दाढ़ी अच्छी है) का पालन करके एक मास्टर बनना नहीं सीखते हैं, आपको उसकी सोच के आंतरिक तरीकों को सीखना चाहिए, और यह कठिन है। और किसी तरह से (नौसिखिए) प्रोग्रामर टीडीडी का अनुसरण करते हुए, अपने सोचने के तरीकों को मास्टर के करीब ले जाते हैं।

Comments

+1 मुझे लगता है कि आपने इसका नाम मैगलोब रखा है। मुझे विशेष रूप से आपकी व्याख्या पसंद है कि "TDD सबसे खराब भागों और आदतों को बाहर निकालने में मदद करता है, [...] अप्रत्यक्ष रूप से गुणवत्ता में वृद्धि"। और लंबी दाढ़ी की उपमा भी बहुत अच्छी है।

— सीजरगॉन

आप एक बुरे कोड के लिए परीक्षण नहीं लिखते हैं, लेकिन आप एक परीक्षण लिखते हैं और फिर परीक्षण पास बनाने के लिए कोड लिखते हैं।

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

— फिलिप डुपनोविक

Answer 11

"पास होने तक टेस्ट + रिफ्लेक्टर लिखो" दृष्टिकोण अविश्वसनीय रूप से इंजीनियरिंग विरोधी है।

आपको रिफैक्टरिंग और टीडीडी दोनों के बारे में गलत धारणा है।

कोड रीफैक्टरिंग सॉफ्टवेयर के कुछ गैर-गुणात्मक विशेषताओं को बेहतर बनाने के लिए अपने बाहरी कार्यात्मक व्यवहार को संशोधित किए बिना कंप्यूटर प्रोग्राम के स्रोत कोड को बदलने की प्रक्रिया है।

इस प्रकार आप कोड को तब तक रिफलेक्टर नहीं कर सकते जब तक यह पास न हो जाए।

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

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

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

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

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

सिविल इंजीनियरिंग के विपरीत, सॉफ्टवेयर इंजीनियरिंग में एक परियोजना आमतौर पर लगातार विकसित होती है। सिविल इंजीनियरिंग में, आपको स्थिति ए में एक पुल बनाने की आवश्यकता होती है, जो x टन ले जा सकता है और प्रति घंटे n वाहनों के लिए पर्याप्त चौड़ा है।
सॉफ्टवेयर इंजीनियरिंग में, ग्राहक मूल रूप से किसी भी बिंदु पर निर्णय ले सकता है (संभवतः पूरा होने के बाद), वह एक डबलडेक ब्रिज चाहता है, और वह चाहता है कि वह निकटतम मोटरवे के साथ जुड़ा हो, और वह इसे एक उठाने वाला पुल बनाना चाहेगा, क्योंकि उसकी कंपनी हाल ही में नौकायन जहाजों का उपयोग करना शुरू किया।
सॉफ्टवेयर इंजीनियरों को डिजाइन बदलने का काम सौंपा जाता है। इसलिए नहीं कि उनके डिजाइन त्रुटिपूर्ण हैं, बल्कि इसलिए कि यह मॉडस ऑपरेंडी है। यदि सॉफ्टवेयर अच्छी तरह से इंजीनियर है, तो इसे सभी निम्न स्तर के घटकों को फिर से लिखने के बिना, उच्च स्तर पर पुन: डिज़ाइन किया जा सकता है।

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

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

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

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

Comments

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

— सीजरगॉन

@ केसरगॉन: पोस्ट अपडेट की गई।

— बैक 2 डोस

Answer 12

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

सॉफ़्टवेयर के आधार को बनाने वाले पुस्तकालयों के परीक्षण के अलावा, उन परीक्षणों को लिखें जो आपके उपयोगकर्ताओं के पास सॉफ़्टवेयर / वेबसाइट / जो कुछ भी हैं, उन्हें कवर करते हैं। ये सीधे उपयोगकर्ताओं से आते हैं, और ककड़ी (http://cukes.info) जैसे पुस्तकालय भी आपके उपयोगकर्ताओं को प्राकृतिक भाषा में स्वयं परीक्षण लिखने दे सकते हैं।

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

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

Comments

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

— CesarGon

@ केसरगॉन: मुझे लगता है कि आपके विशिष्ट प्रश्न किसी भी प्रकार के परीक्षण पर लागू होते हैं, केवल टीडीडी पर नहीं। इसलिए मैंने सिर्फ टीडीडी की विशिष्ट विशेषताओं पर ध्यान केंद्रित किया जो 'काम' था।

— सेवेंससीट

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

Answer 13

मुझे लगता है कि आप गलत कोण से पहले बिंदु पर आ रहे हैं।

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

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

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

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

Comments

मेरे पहले बिंदु की अच्छी व्याख्या के लिए, और हांक मूडी के संदर्भ के लिए +1। शानदार।

— सिजेरॉन

धन्यवाद मैं इसकी प्रशंसा करता हूँ। मैं एक तकनीकी दृष्टिकोण / प्रक्रिया के बजाय मनोवैज्ञानिक घटना के रूप में टीडीडी को अधिक देखता हूं। लेकिन इस मामले पर सिर्फ मेरा नजरिया है।

— फिलिप डुपनोविक

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

— gbjbaanb

Answer 14

सॉफ्टवेयर इंजीनियरिंग में टीडीडी अच्छा अभ्यास है, ठीक उसी तरह जैसे अनुप्रयोगों में त्रुटि से निपटने के साथ-साथ लॉगिंग और डायग्नोस्टिक्स में अच्छा अभ्यास है (हालांकि यह त्रुटि से निपटने का हिस्सा है)।

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

TDD आपको औपचारिक रूप से अधिक उत्पादक के रूप में बनाने के लिए उन चरणों को औपचारिक रूप देने और स्वचालित करने का एक तरीका है।

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

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

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

Comments

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

— सीजेरॉन

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

— अर्नेली

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

— gbjbaanb

Answer 15

यदि आप स्वीकार करते हैं कि जितनी जल्दी कीड़े पाए जाते हैं, उन्हें ठीक करने की लागत कम होती है, तो यह अकेले टीडीडी को सार्थक बनाता है।

Comments

क्या आपके पास कोई सबूत है कि कीड़े टीडीडी सेटिंग में जल्द ही पाए जाते हैं? इसके अलावा, TDD के दुष्प्रभावों के बारे में क्या है, जैसे वास्तुकला पर प्रभाव?

— सीजरगॉन

Answer 16

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

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

Comments

-1। बहुत से लोग यह कहते रहते हैं, लेकिन मुझे अभी तक वह जादू नहीं दिखाई दे रहा है जो ऐसा होता है।

— बार्ट वैन इनगेन शनाउ

@ बर्ट वैन इंगन शेनौ, क्या आपने टीडीडी किया है? मैं इसे लगभग 4 वर्षों से कर रहा हूं, और मैंने निश्चित रूप से "जादू" होता देखा है।

— मार्सी

Answer 17

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

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

Answer 18

सॉफ्टवेयर जैविक है, जब संरचनात्मक इंजीनियरिंग ठोस है।

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

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

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

संक्षेप में, मेरा मानना ​​है कि इसके पीछे की सोच यह है कि यदि आपका डिज़ाइन परीक्षण योग्य है, इसलिए यह शिथिल युग्मित है और इसमें चिंताओं का अच्छा पृथक्करण है।

एक साइड नोट पर, मैंने ऐसे एप्लिकेशन देखे हैं जो वास्तव में परीक्षण योग्य थे, लेकिन ऑब्जेक्ट ओरिएंटेड डिज़ाइन परिप्रेक्ष्य से खराब लिखे गए थे।

Answer 19

TDD क्यों काम करता है?

यह नहीं है

स्पष्टीकरण: स्वचालित परीक्षण बिना किसी परीक्षण के बेहतर हैं। हालाँकि मुझे व्यक्तिगत रूप से लगता है कि अधिकांश यूनिट परीक्षण बेकार हैं क्योंकि वे आमतौर पर टॉटोलॉजिकल (परीक्षण के तहत वास्तविक कोड से स्पष्ट बातें कहते हैं) और यह आसानी से साबित नहीं किया जा सकता है कि वे लगातार नहीं, सभी सीमा मामलों को कवर करते हैं (जहां आमतौर पर त्रुटियां होती हैं) )।

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