टेस्ट-प्रथम प्रोग्रामिंग के नुकसान क्या हैं?

Question

यह आजकल सभी गुस्से में है। “हर कोई इसकी सिफारिश करता है। उस में और खुद मुझे संदिग्ध बना देता है।

टेस्ट-फ़र्स्ट (टेस्ट-संचालित) डेवलपमेंट करते समय आपको कौन से नुकसान हुए हैं? मैं ज्ञानी चिकित्सकों से व्यक्तिगत अनुभवों की तलाश कर रहा हूं - मैं इंटरनेट पर अन्य जगहों पर एक सौ वानाबेस के काल्पनिक संगीत को पढ़ सकता हूं।

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

Answer 1

काफी कुछ हैं, लेकिन फायदे नुकसान से आगे निकल जाते हैं।

वहाँ एक कठिन सीखने की अवस्था है।

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

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

आप अधिक कोडिंग करते हैं।

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

प्रबंधकों को एक कठिन बिक्री हो सकती है।

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

साथी डेवलपर्स के लिए एक कठिन बिक्री हो सकती है।

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

अंत में, फायदे नुकसान से आगे निकल जाते हैं, लेकिन यह मदद नहीं करता है यदि आप नुकसान को अनदेखा करते हैं। यह जानकर कि आप शुरू से ही सही से काम कर रहे हैं, आपको कुछ बातचीत करने में मदद मिलती है, यदि नहीं, तो सभी नुकसान।

Comments

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

— एलेक्स फ़ेमैन

कुछ स्पष्टीकरण देने के लिए अपडेट किया गया

— जैको प्रीटोरियस

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

— ChrisF

@ जेफ़ो आप "मैं खुद को मिनिवैन लिखने जा रहा हूं!" कोडिंग का स्कूल?

— एलेक्स Feinman

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

— ChrisF

Answer 2

टेस्ट-प्रथम मानता है कि आप कोड लिख रहे हैं:

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

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

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

उदाहरण:

मेरा व्यक्तिगत सबसे अच्छा उदाहरण है जब asp.net के लिए सुरक्षा कोड लिखना। अगर वे मशीन के विन्यास से शत्रुतापूर्ण वातावरण में चलने के लिए हैं, तो उन्हें gac'ed, हस्ताक्षरित और सील किया जाता है, और क्योंकि वे IIS देव वस्तुओं के खिलाफ चल रहे हैं, उन्हें सही ढंग से बहुत मुश्किल से नकल करना मुश्किल है। प्रदर्शन और स्मृति उपयोग के लिए कुछ बाधाओं में जोड़ें और आप शेष क्षेत्रों में प्लेसहोल्डर ऑब्जेक्ट्स का उपयोग करने के लिए लचीलापन बहुत जल्दी खो देते हैं।

किसी भी प्रकार के माइक्रो कंट्रोलर या अन्य लो रिसोर्स एनवायरनमेंट कोड को सही मायने में OO स्टाइल डिजाइन करना संभव नहीं हो सकता है क्योंकि एब्सट्रैक्ट आउट ऑप्टिमाइज़ नहीं करते हैं और आपके पास कम संसाधन सीमाएँ हैं। वही कई मामलों में उच्च प्रदर्शन दिनचर्या के लिए भी कहा जा सकता है।

Comments

क्या आप कुछ प्रतिपक्ष दे सकते हैं? जब मैं एक इकाई-परीक्षण तरीके से परीक्षण करने योग्य कुछ नहीं लिखूंगा? मैं ऐसा कोड क्यों नहीं लिखूंगा जो नकली या इंजेक्टेबल हो (विरासत कोड के अलावा, जो खुद के लिए एक विषय है)?

— बजे एलेक्स फेइमैन

उदाहरण अनुभाग को जोड़ने के लिए संपादित

— बिल

माना। TDD काम कर रहा है मशीनों के बारे में मान्यताओं के एक सेट पर भरोसा करने के लिए आप के साथ काम कर रहे हैं; यह मेरी परियोजनाओं के लगभग 50% के लिए सही नहीं लगता है।

— पॉल नाथन

मैं पूरी तरह से सहमत हूँ ... बहुत अच्छा जवाब

— Khelben

यह इस खेल में कुछ भी पसंद है - कई स्थितियों के लिए उपयुक्त, दूसरों के लिए अनुपयुक्त। सॉफ्टवेयर विकास के किसी भी क्षेत्र में वन ट्रू पाथ की वकालत करने वाले किसी से भी सावधान रहें ।

— एलन बी

Answer 3

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

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

दूसरे शब्दों में, TDD (या उस मामले के लिए सॉफ़्टवेयर विकास में कुछ भी) के साथ व्यावहारिक और उचित हो।)

Comments

क्या, शायद, जहां माइकल फेदर की "नई" लिगेसी कोड की परिभाषा (यानी "टेस्ट के बिना कोड") आती है?

— Phill W.

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

— luis.espinal

Answer 4

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

हालांकि, दो समस्याएं हैं जो काफी ध्यान देने योग्य हैं।

टेस्ट सूट का रखरखाव करना होगा

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

समय-समय पर परीक्षण अमूर्त रिसाव

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

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

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

Comments

+1। "बनाए रखा जाना चाहिए": पुन: प्रयोज्य कोड का परीक्षण करते समय यह एक समस्या से बहुत कम है, क्योंकि इसके इंटरफ़ेस और व्यवहार को सामान्य रूप से स्थिर करने की आवश्यकता है। इस कारण से, मैं आमतौर पर केवल हमारे पुन: प्रयोज्य पुस्तकालय के लिए टीडीडी करता हूं।

— दिमित्री सी।

Answer 5

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

शायद यह सिर्फ मैं ही हूं। लेकिन मैंने भी कहीं पढ़ा है कि सभी तरह की सुरक्षा घंटियाँ और सीटी वाली कारें अधिक दुर्घटनाग्रस्त होती हैं (क्योंकि ड्राइवरों को पता है कि सुरक्षा सुविधाएँ हैं), इसलिए शायद यह स्वीकार करने के लिए कुछ है; टीडीडी कुछ व्यक्तियों के साथ असंगत हो सकता है।

Comments

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

— मैट एच

यह सिर्फ दिखाता है कि विभिन्न लोग वास्तव में अलग तरह से प्रतिक्रिया करते हैं। मैं TDD को कोस नहीं रहा हूं - जाहिर है कि काफी लोग इसे उपयोगी पाते हैं - लेकिन तथ्य यह है कि यह हर किसी के लिए नहीं है।

— जूनस पुलकका

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

— बेन ली

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

— बेन ली

क्या आप रिफैक्टिंग कदम को छोड़ रहे हैं?

— rjnilsson

Answer 6

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

मेरा दृष्टिकोण सामान्य रूप से है:

1. किसी ऐसी चीज को लागू करें जो (अवधारणा का प्रमाण) चलती है।
2. यदि यह काम करता है, तो परीक्षणों को जोड़कर, डिजाइन में सुधार, रीफैक्टरिंग को मजबूत करें।

कभी-कभी मुझे चरण 2 तक नहीं मिलता है।

इस मामले में, TDD का उपयोग करने से मेरे लिए फायदे की तुलना में अधिक नुकसान हुए हैं:

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

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

Comments

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

— utnapistim

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

— जियोर्जियो

@utnapistim: luis.espinal का उत्तर भी देखें: "मैंने जो सबसे बड़ी कमी देखी है, वह TDD के साथ नहीं बल्कि चिकित्सकों के साथ है। वे एक हठधर्मी और उत्साहपूर्ण दृष्टिकोण लेते हैं, जहाँ हर चीज़ का परीक्षण होना चाहिए।"

— जियोर्जियो

Answer 7

TDD का नुकसान या लागत

नोट: विभिन्न प्रकार के TDD की एक श्रृंखला है। चाहे यूनिट, BDD, ATDD, या अन्य कई प्रकार की कठिनाइयाँ रहें

दुष्प्रभाव

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

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

आपको कोडिंग के लिए अपना दृष्टिकोण बदलना होगा, कुछ के लिए यह एक कठोर बदलाव होगा।

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

यह समझने में समय लगता है कि आप परीक्षण के बारे में क्या परवाह करते हैं और परीक्षण के बारे में आपको क्या परवाह नहीं है।

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

यूनिट टेस्ट विशिष्ट: बड़े रिफ्लेक्टर

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

Answer 8

मेरे सादृश्य एक स्केलटेक्ट्रिक ट्रैक पर बाधाओं है। यदि आप उन्हें लगाते हैं, तो आप बहुत कम सतर्क रहते हैं।

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

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

Answer 9

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

Comments

यदि आप स्वयं अपने स्वयं के कोड को नहीं समझते हैं, तो संभावित टेस्टकेस के अरबों के बीच मुट्ठी भर लोग कोड के गलत होने के खिलाफ संभवतः पहरा दे सकते हैं?

— माइकल शॉ

क्योंकि आपने इसे तब लिखा था जब आपने इसे लिखा था लेकिन इसके बारे में भूल गए थे?

— जोहान

+1 टीडीडी एक ऐसे डेवलपर के खिलाफ सुरक्षा नहीं करता है, जिसने व्यवसाय की आवश्यकता को गलत समझा है। यह वह जगह है जहाँ BDD आता है ...

— रोबी डी