टेस्ट प्रेरित विकास के नुकसान? [बन्द है]

Question

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

केवल नकारात्मक सूची; नकारात्मक रूप में लिखे गए लाभों को सूचीबद्ध न करें।

Comments

मैंने कहा कि BDD इनमें से कुछ नकारात्मक को कम कर सकता है। मैं आपसे अपने नकारात्मक इनपुट को एकत्रित करते समय इस कारक पर विचार करने का आग्रह करता हूं, क्योंकि इसमें से कुछ को समाप्त किया जा सकता है और अब नकारात्मक नहीं माना जा सकता है।

— किल्होफर

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

— IanL

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

— जिम हर्न

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

— लुईस

कृपया महत्वपूर्ण प्रश्नों को बंद करना बंद करें, djesus

— Casper Leon Nielsen

Answer 1

कई डाउनसाइड्स (और मैं यह दावा नहीं कर रहा हूं कि कोई लाभ नहीं है - खासकर जब किसी परियोजना की नींव लिखते समय - यह अंत में बहुत समय बचाएगा):

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

Comments

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

— आदि

यह सच है, लेकिन यह TDD के बिना एक ही नहीं होगा? इसके बिना, आपको अधिक मैन्युअल परीक्षण करना होगा, जो एक ही समस्या का सामना करेगा।

— sleske

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

— रॉबर्ट कोरिटनिक

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

— आदि

@ आदी: मुझे लगता है कि आप गलत हैं। मेरी राय में हर प्रणाली को उस तरह से परखा जा सकता है, यह केवल आत्म-अनुशासन की बात है।

— BlueLettuce16

Answer 2

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

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

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

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

कई डेवलपर्स बिल्कुल समझ नहीं पाते हैं कि इन सभी को "सही तरीके से" कैसे किया जाए। लेकिन क्योंकि हर कोई उन्हें बताता है कि सॉफ्टवेयर विकसित करने के लिए TDD ही एकमात्र सच्चा तरीका है, वे बस वह सबसे अच्छा प्रयास करते हैं जो वे कर सकते हैं।

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

उन सभी परीक्षणों से आपके सिस्टम के व्यवहार और सरल परिवर्तनों के "परिवर्तन" (रीफैक्टरिंग के विपरीत) के लिए बहुत मुश्किल हो जाता है।

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

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

Comments

Pex & Moles जैसे उपकरणों का उपयोग करके आप बहुत आसानी से हर छोटी चीज़ के लिए इंटरफेस लिखने से बच सकते हैं। मोल्स आपकी उस जबरदस्त मदद करेंगे।

— रॉबर्ट कोरिटनिक

इकाई परीक्षण और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की आलोचना की तरह लगता है, न कि TDD।

— plmaheu

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

— TheMorph

मैं इस तथ्य पर सहमत हूं कि एक धुंध में tdd में कूदने से पहले डिजाइन और परीक्षण का ज्ञान है। यह नए भाड़े के साथ परियोजनाओं में महत्वपूर्ण है क्योंकि वे दोनों के लिए नए हैं।

— हितेश साहू

बुद्धि के लिए मतदान करें

— sababab

Answer 3

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

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

Comments

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

— रोब कूपर

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

— एरिक जेड बियर्ड

+1 "आप TDD के आधार पर डिज़ाइन निर्णय लेना शुरू कर सकते हैं, वास्तव में अच्छे डिज़ाइन के सिद्धांतों पर" - TDD IMHO का सबसे बड़ा नुकसान।

— आंद्रेश स्ज़ेपेश्जी

@ScottSaad समस्या IMO यह है कि डिज़ाइन को पहले उल्लिखित किया जाना चाहिए और फिर परीक्षण लिखकर इसे सत्यापित किया जाना चाहिए और यदि आवश्यक हो तो इसे सही किया जाना चाहिए। मैंने ऐसे कई मामले देखे हैं जब लोग टेस्ट लिखने में सक्षम होने के लिए अच्छे डिज़ाइन को खतरे में डाल रहे थे। नतीजतन - अधिकांश प्रणाली परीक्षणों द्वारा कवर की गई थी लेकिन डिजाइन वास्तव में बदसूरत था। मुझे लगता है कि यह इसलिए होता है क्योंकि TDD निम्नलिखित के साथ बहुत ही सरल पद्धति के रूप में जनता के लिए धकेल दिया जाता है गलत धारणा है : if part of the system is covered by tests and they pass, then everything is fine (including design)।

— यूरी नकोनचाय

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

— BlueLettuce16

Answer 4

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

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

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

तो, (IMO) संक्षेप में:

• सोचने के लिए लिया गया समय (यानी वास्तव में परीक्षण करना )।
• परीक्षण योग्य कोड लिखने का तरीका जानने के लिए आवश्यक नया ज्ञान।
• कोड को परीक्षण योग्य बनाने के लिए आवश्यक वास्तु परिवर्तनों को समझना।
• हमारे शानदार प्रोग्रामिंग क्राफ्ट के लिए आवश्यक अन्य सभी कौशलों को बेहतर बनाने की कोशिश करते हुए "TDD-Coder" के अपने कौशल को बढ़ाना :)
• अपने कोड को अपने उत्पादन कोड को खराब किए बिना परीक्षण कोड को शामिल करने के लिए आधार का आयोजन।

  ---

पुनश्च: यदि आप सकारात्मकता के लिंक चाहते हैं, तो मैंने इस पर कई प्रश्न पूछे हैं और उत्तर दिए हैं, मेरी प्रोफ़ाइल देखें ।

Comments

अफसोस की बात है, पहला उचित जवाब मैंने देखा ...

— डैनियल सी। सोबराल

व्यावहारिक और सरल उत्तर - +1 "माइंड सेटिंग" भाग के लिए

— ha9u63ar

Answer 5

कुछ वर्षों में मैंने टेस्ट ड्रिवेन डेवलपमेंट का अभ्यास किया है, मुझे कहना पड़ेगा कि सबसे बड़ी गिरावट हैं:

इसे प्रबंधन को बेचना

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

इसे अन्य डेवलपर्स को बेचना

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

अपने उत्पादन कोड के साथ परीक्षण कोड बनाए रखना

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

लेखन परीक्षण ताकि आप सब कुछ कवर करें (100% कोड कवरेज)

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

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

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

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

Comments

"(खांसी वीएस टेस्ट), फिर मुख्य" के साथ समाप्त होने वाला बाकी वाक्य क्या था?

— एंड्रयू ग्रिम

बिक्री की समस्या के लिए +1। :) मैं अभी एक नई कंपनी में हूं और यह सोच रहा हूं कि ऐसी संस्कृति कैसे बनाई जाए जो कौशल को स्वतंत्र रूप से फैलाने की अनुमति दे।

— एस्को लुओंटोला

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

— ligiguelvargasf

Answer 6

आपकी पहली टीडीडी परियोजना में दो बड़े नुकसान, समय और व्यक्तिगत स्वतंत्रता हैं

आप समय खो देते हैं क्योंकि:

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

आप व्यक्तिगत स्वतंत्रता खो देते हैं क्योंकि:

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

उम्मीद है की यह मदद करेगा

Comments

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

— जॉन हेनकेल

Answer 7

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

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

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

Comments

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

— शिक्षाविद

मैं वैक्यूम से सहमत हूं। TDD के मूल ट्यूटोरियल जहां आप बिना किसी कोड के परीक्षण लिखेंगे - और एक संकलन त्रुटि प्राप्त कर सकते हैं - पागल है।

— मपरज़

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

— रोमन कोनोवल

Answer 8

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

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

Answer 9

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

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

Comments

अहा - लेकिन यही वह जगह है जहाँ TDTDD आता है। टेस्ट ड्रिवेन टेस्ट ड्रिवेन डेवलपमेंट।

— स्नोक्रैश

मैं अभी भी कभी-कभी अपने परीक्षण परीक्षणों में बग ढूंढ लेता हूं। इसलिए अब मैं TDTDTDD का अभ्यास करता हूं।

— हॉर्सलओवरफ़ैट

@SnowCrash +1 मैं यह देखने के लिए Google के चारों ओर देख रहा था कि लोग अपने परीक्षण का परीक्षण करने में कितना समय बिताते हैं, और फिर मैंने इसका उत्तर देखा। मैंने आधिकारिक तौर पर यह पाया क्योंकि मैं TDTDTDD के बारे में सोच रहा था।

— BalinKingOfMoria CMs

मेरा मानना ​​है कि भविष्य (TD) <सुप> sup </ sup> TDD है। मेरे पास अब तक एक फ़ाइल है: इसमें "x" अक्षर है।

— माइक कृंतक

मैं @Tim से सहमत हूं। सदस्यों को इसे अपनाना सबसे कठिन हिस्सा है।

— ओलू स्मिथ

Answer 10

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

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

Comments

जब से मैं बड़ा हुआ, मुझे कोई पवित्रता खंड में विश्वास नहीं है।

— माईक कृंतक

Answer 11

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

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

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

Comments

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

— मोम_लिकल

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

— सारा

Answer 12

मैंने कई स्थितियों का सामना किया है जहां टीडीडी मुझे पागल बना देता है। कुछ नाम रखने के लिए:

• टेस्ट केस मेंटेनेंस:

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

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

• परीक्षण स्वचालन जटिलता:

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

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

Comments

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

— सारा

Answer 13

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

Answer 14

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

Comments

क्या यह वास्तव में सकारात्मक कहने का नकारात्मक, या धूर्त तरीका है।

— इयानएल

Answer 15

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

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

Answer 16

आप यह कहने की क्षमता खो देते हैं कि आप अपने सभी कोड का परीक्षण करने से पहले "किए गए" हैं।

आप इसे चलाने से पहले कोड की सैकड़ों या हजारों लाइनें लिखने की क्षमता खो देते हैं।

आप डिबगिंग के माध्यम से सीखने का अवसर खो देते हैं।

आप उस कोड को शिप करने के लिए लचीलापन खो देते हैं जिसके बारे में आप निश्चित नहीं हैं।

आप अपने मॉड्यूल को कसकर जोड़े रखने की स्वतंत्रता खो देते हैं।

आप निम्न स्तर के डिज़ाइन प्रलेखन को छोड़ने का विकल्प खो देते हैं।

आप उस स्थिरता को खो देते हैं जो कोड के साथ आती है जिसे हर कोई बदलने से डरता है।

Comments

"समय पर एक समाधान देने" की आपकी परिभाषा पर निर्भर करता है - यह है कि "समय पर किसी भी पुराने, आंशिक रूप से टूटे हुए समाधान" या "समय पर काम करने वाले समाधान वितरित करें"। आप निश्चित रूप से समय पर आंशिक रूप से टूटे हुए समाधान देने की क्षमता को ढीला करते हैं। जहाँ तक देव गति चली जाती है - मुझे मीट्रिक "देव की शुरुआत के बीच का समय बीत गया और दोषरहित लाइव तैनाती का एक सप्ताह" पसंद है। यदि आप इसे निष्पक्ष रूप से मापते हैं, तो गैर-टीडीडी काम के एक कॉप्लेक्स टुकड़े पर भी घड़ी को रोकना मुश्किल है।

— Dafydd रीस

-1, यह बिल्कुल वही बात है जो ओपी ने कहा था कि वह नहीं चाहता था।

— erkkallen

कई सच बयान, लेकिन: क्या erikkallen ने कहा -1।

— j_random_hacker

@ j_random_hacker हैकर कहते हैं ... LOL

— Dan

केवल तीसरा कथन कानूनी है "डिबगिंग के माध्यम से सीखें खो जाता है"

— YEH

Answer 17

मैं प्रारंभिक विकास समय के बारे में दूसरा जवाब देता हूं। आप परीक्षणों की सुरक्षा के बिना भी काम करने की क्षमता खो देते हैं। मुझे TDD नट के रूप में भी वर्णित किया गया है, ताकि आप कुछ दोस्तों को खो सकें;)

Answer 18

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

Answer 19

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

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

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

Comments

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

— BlueLettuce16

Answer 20

यह एक्सएमएल-फीड्स और डेटाबेस जैसे "रैंडम" डेटा के लिए कठिन और समय लेने वाला लेखन परीक्षण हो सकता है (यह कठिन नहीं)। मैंने कुछ समय मौसम डेटा फीड के साथ काम करने में बिताया है। यह काफी भ्रमित करने वाला लेखन परीक्षण है, कम से कम, क्योंकि मुझे टीडीडी के साथ बहुत अधिक अनुभव नहीं है।

Comments

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

— रोब कूपर

Answer 21

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

जेसन कोहेन ने कुछ इस तरह कहा: TDD को आपके कोड के लिए एक निश्चित संगठन की आवश्यकता होती है। यह वास्तुशिल्प रूप से गलत हो सकता है; उदाहरण के लिए, चूंकि निजी तरीकों को एक कक्षा के बाहर नहीं बुलाया जा सकता है, इसलिए आपको उन्हें परीक्षण योग्य बनाने के लिए तरीकों को गैर-निजी बनाना होगा।

मैं कहता हूं कि यह एक चूक का संकेत है - अगर निजी कोड को वास्तव में जांचने की आवश्यकता है, तो यह संभवतः एक अलग वर्ग में होना चाहिए।

दवे मान

Answer 22

आपको अनुप्रयोगों को एक अलग तरीके से लिखना होगा: एक जो उन्हें परीक्षण करने योग्य बनाता है। आपको आश्चर्य होगा कि यह पहली बार में कितना मुश्किल है।

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

टीडीडी एक ऐसा कौशल है जिससे जूनियर देव पहले संघर्ष कर सकते हैं (मुख्यतः क्योंकि उन्हें इस तरह से काम करना नहीं सिखाया गया है)।

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

Answer 23

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

Answer 24

• इकाई परीक्षण लिखने के लिए अधिक कोड हैं, इस प्रकार विकास की एक उच्च अग्रिम लागत है
• यह बनाए रखने के लिए अधिक कोड है
• अतिरिक्त सीखने की आवश्यकता है

Answer 25

सभी के अच्छे जवाब। मैं टीडीडी के अंधेरे पक्ष से बचने के लिए कुछ तरीके जोड़ूंगा:

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

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

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

Comments

रैंडम परीक्षण रुक-रुक कर विफल हो सकते हैं, और उन्हें दोहराना मुश्किल बना सकता है

— डेविड साइक्स

@DavidSykes: जब भी आप एक यादृच्छिक परीक्षण करते हैं, तो आप मापदंडों को रिकॉर्ड करते हैं, ताकि यदि यह विफल हो जाए तो आप इसे दोहरा सकें, या आप इसे बाद में भी दोहरा सकते हैं, भले ही वह विफल न हो। मुद्दा यह है कि आप परीक्षण के मामलों पर विचार करने के लिए आप पर निर्भर नहीं हैं। यदि आप मेरे जैसे हैं तो आप सहज रूप से सुरक्षित परीक्षण मामलों की ओर बढ़ते हैं।

— माइक डनलैवी

Answer 26

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

जब कोड बदलता है, तो आपको परीक्षणों को भी बदलना होगा। इसे फिर से तैयार करने के साथ बहुत सारे अतिरिक्त काम हो सकते हैं।

Comments

सभी निजी तरीकों का परीक्षण उन सार्वजनिक तरीकों के माध्यम से किया जाना चाहिए जो वैसे भी मौजूद होंगे।

— गैरी शॉटलर

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

— जेसन कोहेन

+1, इतना सच। इसे कभी-कभी निजी क्षेत्र में गेटर्स / सेटर जोड़ने की आवश्यकता को केवल एक इकाई परीक्षण के लिए राज्य को सही ढंग से सेट अप करने और पढ़ने में सक्षम होने के लिए जोड़ें, भले ही राज्य कक्षा के लिए निजी हो।

— erikkallen

अपने परीक्षणों को लिखने पर विचार करें जैसे कि यह एक जीवित आवश्यकता दस्तावेज़ है। तब आपको प्रकाश दिखाई पड़ता। इसके अलावा XUnit टेस्ट पैटर्न पढ़ें।

— स्कॉट निमरोड

Answer 27

मुझे जोड़ने दें कि यदि आप BDD सिद्धांतों को TDD परियोजना में लागू करते हैं, तो आप यहाँ सूचीबद्ध कुछ बड़ी कमियों (भ्रम, गलतफहमी, आदि) को कम कर सकते हैं। यदि आप BDD से परिचित नहीं हैं, तो आपको Dan North का परिचय पढ़ना चाहिए। कार्यस्थल पर टीडीडी को लागू करने से उत्पन्न कुछ मुद्दों के जवाब में उन्होंने इस अवधारणा को अपनाया। दान का परिचय बीडीडी को मिल सकता है यहां है ।

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

Comments

पूर्ण रूप से। टीडीडी का मूल्यांकन करते समय आपको बीडीडी पर विचार करना होगा।

— user9991

ऐसा लगता है कि BDD = व्यवहार-चालित विकास

— hayalci 23

Answer 28

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

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

Answer 29

जिस व्यक्ति ने मेरी टीम को फुर्तीला विकास सिखाया था, वह योजना बनाने में विश्वास नहीं करता था, आपने केवल सबसे अधिक आवश्यकता के लिए लिखा था।

उनका आदर्श वाक्य रिफलेक्टर, रिफलेक्टर, रिफलेक्टर था। मुझे समझ में आया कि रिफ्लेक्टर का मतलब 'आगे की योजना नहीं' था।

Answer 30

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

Comments

मैं 36 साल के लिए विकास कर रहा हूं, अब यह पोस्ट आपको कुछ अच्छी सलाह दे सकती है: stackoverflow.com/questions/738539/tdd-how/45971814#45971814

— user2288580