टीडीडी नकारात्मक अनुभव [बंद]

Question

आपके TDD अनुभव का एक नकारात्मक पक्ष क्या है? क्या आपको बेबी स्टेप्स (टेस्ट ग्रीन बनाने के लिए सबसे सरल फिक्स) कष्टप्रद और बेकार लगता है? क्या आपको कोई मूल्य-परीक्षण नहीं लगता है (जब परीक्षण में शुरू में समझदारी होती है लेकिन अंतिम कार्यान्वयन में अन्य परीक्षण के समान तर्क की जांच होती है) आदि।

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

TDD के नकारात्मक पक्षों का वर्णन करने वाले लेखों के लिंक के लिए आभारी होंगे (Google सकारात्मक और अक्सर कट्टर लेखों से भरा हुआ है)।

Comments

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

— एरॉन

क्या आपको इंटरनेट पर नकारात्मकता खोजने में परेशानी हो रही है ?!

— एरिक विल्सन

@ जॉब (और संभवत: अन्य): भूलकर भी टीडीडी के बारे में न कहें, न कि इकाई परीक्षण। टीडीडी! = इकाई परीक्षण।

— n1ckp

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

— री मियासका

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

— एरिक रेपेन

Answer 1

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

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

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

Comments

+1 "नियोजन चरण के हिस्से के रूप में एक उच्च स्तर पर परीक्षणों को डिजाइन करना - वास्तुशिल्प डिजाइन के साथ-साथ" मेरे लिए बहुत अधिक उचित लगता है।

— स्टीवन ज्यूरिस

@Aaronaught Agile का मतलब कोई नियोजन नहीं है , इसका अर्थ है समय नियोजन में।

— एडम जस्क्युविज़ 13

@ अदम जस्कविज़: मुझे "नो अपफ्रंट प्लानिंग" चीज़ पसंद है। चलो, योजना परिभाषा से आगे है । यदि आप पहले से योजना नहीं बनाते हैं, लेकिन घटना के दौरान आप बिल्कुल भी योजना नहीं बना रहे हैं; आप सुधार कर रहे हैं। ;-)

— सेसरगॉन

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

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

— jwenting

Answer 2

यह ( क्लीजुर लेखक) रिच हिकी साक्षात्कार में निम्नलिखित शामिल हैं। मुझे 100% सहानुभूति महसूस होती है:

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

वर्क बुक इंटरव्यू में कोडर्स में डोनाल्ड नथ का एक और समान कथन , यहाँ से कॉपी-पेस्ट किया गया :

सीबिल: प्रैक्टिकल वर्क की बात करें, तो द आर्ट ऑफ़ कंप्यूटर प्रोग्रामिंग पर काम करने के बीच में आपने अपने टाइपिंग सिस्टम टीएक्स को लिखने के लिए दस साल के ब्रेक में क्या बदल दिया। मैं समझता हूं कि आपने कंप्यूटर से पूरी तरह से TeX का पहला संस्करण लिखा था।

नथ: जब मैंने 1977 और '78 में मूल रूप से TeX लिखा, तो बेशक मेरे पास साक्षर प्रोग्रामिंग नहीं थी, लेकिन मेरे पास संरचित प्रोग्रामिंग थी। मैंने इसे पेंसिल में, पेंसिल में एक बड़ी नोटबुक में लिखा था। छह महीने बाद, जब मैं पूरी परियोजना से गुजरा, मैंने कंप्यूटर में लिखना शुरू कर दिया। और डिबगिंग मार्च के '78 में किया था, जबकि मैंने '77 के अक्टूबर में प्रोग्राम लिखना शुरू कर दिया था। स्टैनफोर्ड अभिलेखागार में उस के लिए कोड-यह सब पेंसिल में है - और निश्चित रूप से मैं वापस आऊंगा और एक सबरूटीन को बदलूंगा क्योंकि मैंने सीखा कि यह क्या होना चाहिए। यह एक पहली पीढ़ी की प्रणाली थी, इसलिए बहुत सारे अलग-अलग आर्किटेक्चर संभव थे और जब तक मैं इसके साथ थोड़ी देर के लिए रहता था, तब तक इसे छोड़ दिया जाता था और जानता था कि वहाँ क्या था। और यह एक चिकन और अंडे की समस्या थी - आप तब तक टाइप नहीं कर सकते जब तक आपके पास फोंट नहीं थे लेकिन तब तक आपके पास फोंट नहीं हो सकते थे जब तक आप टाइप नहीं कर सकते थे। लेकिन संरचित प्रोग्रामिंग ने मुझे आक्रमणकारियों और काले बक्से बनाने का तरीका जानने का विचार दिया, जिन्हें मैं समझ सकता था। इसलिए मुझे विश्वास था कि जब मैं अंत में इसे डिबग करूंगा तो कोड काम करेगा। मुझे लगा कि अगर मैं कुछ भी परीक्षण करने से पहले छह महीने इंतजार कर रहा हूं तो मैं बहुत समय बचा सकता हूं। मुझे पर्याप्त विश्वास था कि कोड लगभग सही था।

सीबिल: और समय की बचत होगी क्योंकि आप अपूर्ण कोड का परीक्षण करने के लिए मचान और स्टब्स बनाने में समय नहीं बिताएंगे?

नथ: सही है।

Comments

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

— sebastiangeiger

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

— निकल्स एच

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

— विंस्टन एवर्ट

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

— जूनस पुलकका

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

— मैट एच

Answer 3

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

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

मुझे लगता है कि टीडीडी उपयोगी है, लेकिन मैं इसके बारे में हठधर्मी नहीं हूं। यदि वे "नो-वैल्यू टेस्ट" रखरखाव को मुश्किल बना रहे हैं - उन्हें हटा दें! मैं बाकी कोड की तरह ही टेस्ट करता हूं। यदि इसे दूर किया जा सकता है और चीजों को सरल बनाया जा सकता है, तो इसे करें!

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

Comments

आपने इसे पैराग्राफ 2 में लिया है

— शेल्डन वारकेंटिन

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

— jwenting

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

— स्टीव जैक्सन

"वास्तव में सरल परीक्षण जो कक्षा के इंटर्नल के साथ इंटरव्यू किए गए थे" <- वहीं आपकी समस्या है। केवल सार्वजनिक इंटरफेस का परीक्षण करें। TDD! = UT

— स्टीवन ए। लोवे

@ StevenA.Lowe - मुझे पता है कि अब, लेकिन 9 साल पहले यह इतना स्पष्ट नहीं था :) "TDD एक परीक्षण कौशल नहीं है"

— स्टीव जैक्सन

Answer 4

मैं यहां एक अंग पर जा रहा हूं और क्रूर ईमानदारी के साथ घोषणा करता हूं कि यह शाब्दिक समय का कर्मकांड है। (अधिकांश स्थितियों में)

मैंने यूनिट टेस्टिंग पर एक पुस्तक खरीदी, जिसमें टीडीडी पर भी चर्चा की गई, और जब मैं यूटी के लाभों से सहमत हूं, तो टीडीडी को बाहर करने के लगभग सौ घंटों के बाद, मैंने इसे असंख्य कारणों के लिए छोड़ दिया। मैं यहाँ क्रॉस-पोस्टिंग की तरह हूँ , लेकिन TDD:

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

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

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

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

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

Comments

बहुत दिलचस्प परिप्रेक्ष्य फिर से: अनुष्ठान। आप कुछ अर्थों में भी समझ सकते हैं, कि एक प्रोग्रामर की अपने शिल्प के प्रति प्रतिबद्धता को TDD के पालन के लिए पूरी तरह आनुपातिक माना जाता है।

— 19

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

— jwenting

@jwenting लोग TDD करते हैं क्योंकि वे नहीं जानते कि एक डिज़ाइन मॉड्यूलर क्या होता है, इसलिए वे अपने 40 "बाइक से 35" प्रशिक्षण पहियों को कभी नहीं ले सकते। यदि आप अवधारणाओं को समझते हैं, तो मॉड्यूलर डिजाइन बनाना हमेशा एक प्रबंधनीय कार्य होता है, क्योंकि आपके डिजाइन में प्रत्येक दुविधा इस तथ्य के कारण प्रबंधनीय आकार की होगी कि यह गर्भाधान में, मॉड्यूलर बनने की प्रक्रिया में है। मैं इस बात से असहमत नहीं हूं कि टीडीडी मॉड्युलैरिटी के लिए मजबूर करने के लिए प्रभावी है, लेकिन मैं असहमत हूं कि किसी को मॉड्यूलर डिजाइन बनाने में मजबूर होना पड़ता है । मॉड्यूलर डिजाइन एक पूरी तरह से मिलनसार और सीखने योग्य कौशल है।

— री मियासका

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

— री मियासाका

@ उस साक्षात्कार में, वह कहते हैं, "लगभग 15 से 35% अधिक समय" - केवल 15% नहीं जैसा कि आपने उसे उद्धृत किया है। अध्ययन में केवल जावा / सी ++ / सी # (शायद सी # 2, दी गई तारीख) शामिल है - एक ही अनिवार्य ओओपी प्रतिमान की सभी भाषाएं। मैं निश्चित रूप से 15% से अधिक और शायद एक कार्यात्मक भाषा में 35% से अधिक उत्पादक हूं (और सी # 3 में भी), और मैं बहुत कम बगों को स्टेटलेस, कंपोजेबल कोड लिख रहा हूं - उसी प्रकार के कीड़े जो अम्लीरेट का परीक्षण करते हैं, क्योंकि दोनों चीजें एक ही तरह की समस्याओं को हल करती हैं। दूसरे शब्दों में, निश्चित रूप से, कीड़े में 60-90% की कमी, लेकिन क्या तुलना में ?

— री मियाकाका

Answer 5

जोड़ने के लिए, TDD के साथ एक और चिंता मैंने देखी है:

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

मैं एक आदमी को जानता हूं जो एक प्रबंधक है और तकनीकी रूप से सुस्त है एक बार टीडीडी के साथ ग्रस्त हो गया। यह उनके लिए ऐसी जादुई बात थी कि उनका मानना ​​था कि उनके खराब आर्किटेक्चर वाले सॉफ्टवेयर में कम से कम रख-रखाव कोड वाले सभी मुद्दों पर जादुई समाधान आएगा। यह कहने के लिए नहीं कि उस परियोजना का क्या हुआ-यह उसके हाथों बुरी तरह विफल रही, जबकि उसके सभी परीक्षण हरे थे। मुझे लगता है कि टीडीडी ने उन्हें किसी तरह की सांख्यिकीय जानकारी प्राप्त करने में मदद की जैसे "99/100 मेरे मामले हरे हैं" आदि और यही उनके जुनून का कारण था क्योंकि वे कभी भी गुणवत्ता का मूल्यांकन करने या डिजाइन में वृद्धि का सुझाव देने में सक्षम नहीं होंगे।

Comments

PHB नरक की तरह लगता है! यह मुझे उन कंपनियों की याद दिलाता है जो बोनस स्कीम पेश करती हैं - बेशक ऐसा होता है कि डेवलपर्स क्वालिटी कोड पर ध्यान देने के बजाय, बोनस जो भी हो, उसे पूरा करने पर ध्यान दें। अनिवार्य रूप से आपको क्रैपीयर कोड मिलता है। (वर्तमान बैंकिंग संकट :-) के लिए यहां एक सादृश्य भी है)

— ट्रोजननाम

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

— एलेक्स

कोड कवरेज यूनिट टेस्टिंग की चिंता है, टीडीडी की नहीं । टीडीडी केवल सार्वजनिक इंटरफेस के माध्यम से सुविधाओं और परीक्षणों की परवाह करता है।

— स्टीवन ए लोव

Answer 6

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

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

दूसरी तरफ, TDD प्रोजेक्ट में बग्स / फीचर्स को जोड़ना बहुत सीधा हो जाता है। स्वभावतः, TDD के साथ लिखा गया कोड आमतौर पर छोटे टुकड़ों के साथ काम करने के लिए काफी कम होता है।

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

Comments

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

— टॉम केर

यह TDD के साथ एक नकारात्मक अनुभव नहीं है, यह भद्दा कोड वाला एक नकारात्मक अनुभव है।

— री मियासका

Answer 7

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

यह कहा जा रहा है, यदि आपके पास रेल की तरह एक ढांचा है जहां आपके वास्तु निर्णय बहुत सीमित हैं तो ये समस्याएं मूल रूप से अस्तित्वहीन हैं।

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

Comments

शायद आपको अपने परीक्षणों के लिए कुछ परीक्षण लिखने चाहिए! : पी ...... आई किड, आई किड

— ऐरन

+1 +1 +1 +1 (यदि मेरे पास 3 डमी खाते हैं)। वाक्य # 2 बहुत ही रमणीय और टीडीडी पुष्टिकरण पूर्वाग्रह से मुक्त है जो अब तक बहुत प्रचलित है।

— tgm1024

Answer 8

टीडीडी के एक बड़े प्रशंसक के रूप में मैं कभी-कभी इन कमियों को देखता हूं

• लगभग 100% कोड कवरेज के लिए बहुत सारे परीक्षण लिखने के लिए प्रलोभन । मेरी राय में परीक्षण लिखना आवश्यक नहीं है
  • सरल संपत्ति पाने वालों / बसने वालों के लिए
  • हर मामले के लिए जब एक अपवाद फेंक दिया जाता है
  • जो विभिन्न परतों के माध्यम से समान कार्यक्षमता की जाँच करता है। (उदाहरण: यदि आपके पास हर पैरामीटर के लिए इनपुट सत्यापन की जांच करने के लिए एकमत है तो एकीकरण परीक्षण के माध्यम से इन सभी परीक्षणों को दोहराना आवश्यक नहीं है)

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

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

Comments

+1: "लगभग 100% कोडेक की खातिर बहुत सारे परीक्षण लिखने के लिए प्रलोभन।" यूनिट परीक्षणों द्वारा कवर नहीं किया गया और कोड चरण-दर-चरण डीबग करके आसानी से पाया जा सकता है।

— जियोर्जियो

Answer 9

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

हो सकता है कि किसी दिन, मेरा मन बदल जाएगा, लेकिन एक्सपी प्रथाओं के बीच, निर्दयता से व्यवहार करने का विचार , और अपने स्वयं के रूप को विकसित करने वाले कोड कहीं अधिक महत्वपूर्ण हैं और मेरे लिए सबसे बड़ी उत्पादकता का नेतृत्व करते हैं, सीएफ। जेम्स न्यूकिर्क के एक पेपर का एक उद्धरण :

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

साहस की अवधारणाएं और प्रतिक्रिया कसने की लूप्स, जिसका वह उल्लेख करती हैं, मेरे दिमाग में, उत्पादकता की कुंजी भी हैं।

Comments

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

— मार्क बूथ

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

— इंजीनियर

यह भी ध्यान देने योग्य है कि जिस दर पर सिमुलेशन चलते हैं, वह वास्तविक समय, ऑनस्क्रीन में चर देखना बेहतर होता है, क्योंकि इस तथ्य को पोस्ट करने के लिए मिलियन-लाइन लॉगफाइल्स के साथ बैठना पड़ता है।

— इंजीनियर

यूनिट टेस्ट मेरे अनुभव में, रिफैक्टिंग को बहुत आसान बनाते हैं।

— टॉम केर

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

— कोडर

Answer 10

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

यह शायद मदद नहीं करता है कि अक्सर मैं पूरी कंपनी का एकमात्र व्यक्ति हूं जो जानता है कि यूनिट परीक्षण (टीडीडी या अन्यथा) क्या है और यह एक अच्छी बात क्यों है।

Comments

यह वह जगह है जहां मजाक चौखटे में आते हैं। इन्स्तांत Fooसाथ मॉक बजाय वस्तुओं Quuxऔर Bazसीधे, तो आप समारोह आप परीक्षण करने के लिए और उसके बाद जाँच लें कि mocks कार्यों जैसा कि आप उम्मीद के साथ कहा जाता था चाहते हैं कॉल कर सकते हैं। मॉक ऑब्जेक्ट्स सक्षम करने वाली तकनीक हैं जो इकाइयों को डिकूप करने में मदद करती हैं और उन्हें इकाई परीक्षण योग्य बनाती हैं। यही कारण है कि एकमात्र बुराई कर रहे हैं, जब से तुम अक्सर बस नहीं कर सकते नकली उन्हें बाहर। * 8 ')

— मार्क बूथ

Answer 11

टीडीडी zealots।

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

IMO, उनका सबसे बड़ा झूठ यह है कि TDD आपको एक बेहतर एल्गोरिदम डिज़ाइन का उद्धार करेगा । TDD में लिखा गया प्रसिद्ध सोडुकु सॉल्वर देखें: यहाँ , यहाँ , यहाँ , यहाँ और यहाँ

और इसकी तुलना पीटर नॉर्विग सुडोकू सॉल्वर ने टीडीडी का उपयोग करके नहीं की, बल्कि पुराने जमाने की इंजीनियरिंग का उपयोग करके किया: http://norvig.com/sudoku.html

Comments

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

— Zombies

अकेले परीक्षण संचालित विकास में पूर्ण पाठ्यक्रम और जो वास्तव में सही ट्रैक पर डेवलपर्स को प्राप्त करता है (जैसा कि सी ++ में लिंक की गई सूची को लागू करने के लिए विरोध किया गया है)।

— लाश

कड़ियाँ टूटी हैं यार!

— lmiguelvargasf

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

— आउटिंग

लोल यार मैं ट्रोल हो रहा था ... मैंने लिखा था कि बहुत पहले मैं उस छोटे से मणि के बारे में भूल गया था।

— लाश

Answer 12

यदि आप इन "कट्टर" लेखों से टीडीडी का उपयोग करते हैं, तो आपको गलत सुरक्षा महसूस होगी कि आपके सॉफ़्टवेयर में कोई त्रुटि नहीं है।

Comments

क्या आप यह जानकर की तुलना में कोई अन्य भावना प्राप्त कर सकते हैं कि इनपुट के एक सेट के लिए आपका सॉफ़्टवेयर आउटपुट का एक सेट देता है?

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

— Dainius

Answer 13

TDD के कुछ लाभ हैं:

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

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

मैं एक विमान के लिए चेकलिस्ट के समान बच्चे के कदम के साथ टीडीडी लाल-हरा-चक्र पर विचार करता हूं। विमान में टेक-ऑफ से पहले प्रत्येक वस्तु की जाँच करना कष्टप्रद और थकाऊ होता है, खासकर अगर यह सामान्य तौर पर सरल (टीडीडी बेबी स्टेप्स) है, लेकिन यह पाया गया है कि यह सुरक्षा को बढ़ाता है। हर काम की पुष्टि करने के अलावा, यह अनिवार्य रूप से विमान को रीसेट करता है । दूसरे शब्दों में, हर टेक-ऑफ से पहले एक विमान को रिबूट किया जाता है।

Comments

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

— स्टीवन ज्यूरिस

प्रश्न टीडीडी के लाभों के बारे में नहीं पूछ रहा था। उस पर पहले से ही बहुत सारे अन्य प्रश्न हैं।

— हारून

@ आनंद, मैं उनके दर्द बिंदुओं को संबोधित कर रहा हूं।

उत्तर प्रश्न को संबोधित करना चाहिए ।

— एरोन

@ हारून, तो उन में से कुछ लिखें।

Answer 14

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

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

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

Comments

+1 उत्कृष्ट टिप्पणी। यह वास्तव में या तो एक ही सच्चा तरीका है या कोई रास्ता नहीं है।

— unpythonic

Answer 15

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

Comments

आमतौर पर एक दूसरा प्रयास आपको पहले प्रयास, टीडीडी या नहीं की तुलना में समस्या में अधिक अंतर्दृष्टि देगा।

— wobbily_col

Answer 16

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

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

सिस्टम की हिम्मत को आसानी से लागू किया गया था, और प्रत्येक उप-प्रणाली के लिए जिम्मेदार होना चाहिए यह निर्दिष्ट करने के लिए टीडीडी यहां उपयोगी था।

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

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

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