सहकर्मी इकाई परीक्षणों का उपयोग करने के लिए तैयार नहीं है "क्योंकि यह कोड के लिए अधिक है"

25

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

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

तो मेरे लिए सबसे अच्छा तरीका क्या है?

refactoring unit-testing

— billy.bob
स्रोत

3

इकाई परीक्षणों को लिखने के लिए होने वाला विरोधाभास शायद आपके सहकर्मी के साथ सामान्य इकाई परीक्षण कार्यान्वयन के व्यवस्थित ओवरहेड की तुलना में कम है।

— mario

2

@ नाम: कृपया मेरी प्रतिक्रिया @ m.edmondson पर देखें।

— doppelgreener

अच्छा!! आपके लिए कम प्रतियोगिता !!

@

— जोनाथन

@ m.Edmondson - नई नौकरी .... यह मेरी टिप्पणी का हिस्सा है कि गाल में एक छोटी सी जीभ थी, लेकिन यह काम करने के लिए एक बेकार जगह की तरह लगता है, पुराने तकनीक, समझदार देव अभ्यास का उपयोग करने के लिए इच्छुक नहीं हैं।

— 14

23

वह इकाई परीक्षण के लाभों से अवगत नहीं है और यही आपको बदलने की आवश्यकता है:

उसकी जागरूकता।

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

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

अपने आप को तैयार करने के लिए, आपको सभी चीजों के लिए P.SE या Google पर देखना चाहिए, प्रबंधन या डेवलपर्स इकाई परीक्षण के बारे में चिंतित हैं और उन उत्तरों का संकलन करें जिनका उपयोग आप अपने सहकर्मी के साथ चर्चा के दौरान करेंगे।

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

20

एक आइटम की सूची से प्यार करें। +1

— आर्मंड

1

यदि आप सूची के ठीक बाद रुक जाते तो यह उत्तर सही होता। +1 :)

— टिम पोस्ट

एसओ चुनावों में अपने दूसरे स्थान के लिए हे टिम बधाई!

6

मुझे लगा कि इस सूची में अपने स्वयं के पाई चार्ट के हकदार थे।

— टॉमस

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

— पत्थरबाज

15

एक इकाई परीक्षण लिखें (उसे न बताएं)

बात के टूटने तक प्रतीक्षा करें, उसे दो दिनों के लिए मैनुअल परीक्षण करने दें, फिर अपनी इकाई के परीक्षण को बाहर निकालें और तीन सेकंड में बग का पता लगाएं।

कवर ले...

— थर्स्टन मुलर
स्रोत

1

+1 यह दर्शाने के लिए कि बग्स अपरिहार्य हैं और कवर लेना है।

— नील

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

— JBRWilkinson

3

@JBRWilkinson: Merb (पूर्व रूबी वेब एप्लीकेशन फ्रेमवर्क) ने ठीक यही किया। हालांकि यूनिट परीक्षणों के साथ नहीं, लेकिन कार्यात्मक परीक्षणों के साथ। वास्तुकला "व्यवस्थित" हो गया था, और जब फ्रेमवर्क का उपयोग करना अच्छा था , तो इसे बनाए रखना और विस्तारित करना अच्छा नहीं था । और चिरस्थायीता और व्यापकता वास्तव में रेल्स पर अपने प्रतिद्वंद्वी रूबी के प्रमुख विक्रय बिंदुओं में से दो थे, उन्हें स्पष्ट रूप से इसके बारे में कुछ करने की आवश्यकता थी। और क्या उन्होंने किया था सचमुच के rm -rfस्रोत और इकाई परीक्षण निर्देशिका, केवल कार्यात्मक परीक्षण रखने, और बस उन्हें एक एक करके फिर से एक गुजर मिलता है।

— जॉर्ग डब्ल्यू मित्तग

11

स्वचालित रूप से अन्यथा मैन्युअल कार्यों को किसी भी प्रोग्रामर से अपील करना चाहिए।

इसलिए वह "अधिक कोड नहीं लिख रही है" वह मैन्युअल रूप से कम कर रही है।

— लेस
स्रोत

1

निर्भर करता है कि आपके पास एक परीक्षण टीम है जो आपके लिए वह सब कुछ करती है :)

— gbjbaanb

11

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

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

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

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

हालांकि, अगर वह आश्वस्त नहीं है, तो आपको कठिन तथ्यों को एकत्र करने की आवश्यकता हो सकती है । ऐसे तथ्य हो सकते हैं

आपके बनाम उसके द्वारा लिखे गए कोड में दोष दर
उसके कोड के खिलाफ इकाई परीक्षणों का एक सेट लिखना और उसमें पाए जाने वाले कीड़े का दस्तावेजीकरण करना।

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

— पेटर टॉर्क
स्रोत

अत्यधिक संभावना नहीं है - हालांकि इसकी परीक्षण योजनाओं के लिए अज्ञात नहीं है (एक्सेल दस्तावेज़) पृष्ठ लंबे

— billy.bob

@ m.edmondson, हाँ, यह सिर्फ एक लफ्फाजी का सवाल था :-)

— Péter Török

पुनरावृत्ति के लिए +1। मैं एक आक्रामक रिफ्लेक्टर (एर) हूं, और मुझे इस तथ्य से प्यार है कि मैं पूरी तरह से कोड के एक खंड को फिर से लिखने पर बहुत जल्दी पा सकता हूं।

— माइकल के

3

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

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

— TZHX
स्रोत

हम .NET 1 पर हैं (एक मजाक मुझे पता है) - क्या यूनिट परीक्षण यहां लागू किया जा सकता है?

— billy.bob

1

@ m.edmondson: शायद NUnit जैसा कुछ? ( nunit.org )

— हनीबल

@ डॉ। हनिबल लेक्टर - यूए मुझे लगता है कि हमें इसकी एक प्रति मिल गई है कहीं बीमार तो नहीं, अगर मैं इसे पा

— सकूँ

4

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

— TZHX

3

शैतानों की वकालत करने के लिए: उसके पास एक बिंदु है। मैं आमतौर पर इसे इस रूप में देता हूं:

स्वचालित परीक्षण बहुत अधिक कोड वाली समस्याओं को अधिक कोड के साथ हल करते हैं।

दलील:

गलती दर और OO मेट्रिक्स के सहसंबंध के बारे में अध्ययन , शीर्षक परिणाम: "आकार के लिए नियंत्रित करने के बाद [वर्ग का] हमने जो भी मेट्रिक्स का अध्ययन किया, उनमें से कोई भी गलती-त्रुटि से जुड़ा नहीं था" । (अध्ययन कक्षा के आकार पर चर्चा करता है। क्या यह प्रभाव कोड आधार के आकार तक विस्तारित है? शायद मेरी राय में )
जाहिर है, बड़ी परियोजनाएं धीरे-धीरे आगे बढ़ती हैं। "एक नई परियोजना में रातोंरात 5K लाइनें" बनाम "बड़े पैमाने पर 10 लाइनें / दिन"। क्या कोड आधार के आकार के साथ बढ़ते हुए "प्रतिरोध" को इंगित करता है?
हम हमेशा घोषणा करते हैं "कोई सबसे अच्छी भाषा नहीं है, यह समस्या पर निर्भर करता है।" एक प्रमुख आवश्यकता समस्या संस्थाओं और संचालन को पसंद की भाषा में आसानी से मॉडलिंग करना है। नहीं है कि एक भाषा चुनने सुझाव है जहां आपकी समस्या को व्यक्त करने और अधिक व्यापक है बदतर है, और नहीं है कि फिर से कोड के आधार के अंतिम आकार के साथ संबंध स्थापित?

अब, उस के खिलाफ आसानी से आग लगाने के कुछ तर्क हैं। मुझे उन लोगों के बारे में बताएं जिनके बारे में मैं सोच सकता हूं:

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

TL; DR: मेरा तर्क नहीं है कि यूनिट परीक्षण खराब हैं; मैं पूछता हूं: क्या एक ब्रेक-सम प्वाइंट है जहां परीक्षणों से चोट लगी है जो कोड की मात्रा से संबंधित है?

— peterchen
स्रोत

2

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

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

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

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

यदि टीम हालांकि एक आम सहमति तक नहीं पहुंच सकती है कि आपको इकाई परीक्षण लिखना चाहिए, तो मेरा सुझाव है कि आप एक अलग विकास टीम के साथ काम करने के लिए मिलेंगे);

— पीट
स्रोत

2

क्या वह बॉस है?

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

क्या वह बॉस नहीं है?

जहां आप काम करते हैं, वहां कोडिंग मानक क्या हैं? क्यों उसे स्पेगेटी कोड को बाहर निकालने की अनुमति है? एक व्यावसायिक मामला बॉस को यह कहते हुए पेश करें कि "अगर हम टीडीडी पर थोड़ा और समय बिताते हैं, तो हम कीड़े पर कम समय बिताएंगे"। किसी ऐसे व्यक्ति को समझाना जो किसी व्यवसाय के मामले में परिवर्तन लागू कर सकता है।

दस्तावेज़ मामले जहां TDD समय और $ $ बचा सकता है पैसा $ $।

इस कीड़े ने खुद को प्रस्तुत किया। लाइव होने से पहले इसे पकड़ा गया होगा। 2 घंटे की रोकथाम के खर्च ने हमें 10 घंटे के इलाज से बचाया होगा। यह यहाँ और यहाँ और यहाँ हुआ। उस 10 घंटे के काम ने कंपनी को 30 आदमी घंटे बचाए होंगे। यही बहुत पैसा है।

— WernerCD
स्रोत

1

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

— 17

1

यह मुझे कुछ संशोधित करने की स्थिति में छोड़ देता है

क्यूं कर?

उन्होंने समस्या पैदा की। उन्हें इसका हल निकालना चाहिए।

क्या प्रबंधक ऐसा होने दे रहा है? किसी और का छोटी गाड़ी कोड अब आपकी समस्या क्यों है?

आपके पास एक सहयोगी और एक प्रबंधक है जो दोनों ऐसा कर रहे हैं। और उनकी गंदगी को साफ करके, आप एक इच्छुक और सक्रिय भागीदार हैं।

खराब गुणवत्ता के दर्द को महसूस नहीं करने पर कुछ भी नहीं बदलेगा।

— S.Lott
स्रोत

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

— JBRWilkinson

1

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

— S.Lott

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

— सारा

1

वह काफी सही है, इकाई परीक्षण "अधिक कोड" हैं।

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

उसे चुनौती दें:

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

— rupjones
स्रोत

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

— सारा

1

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

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

— ब्रायन नॉबलुच
स्रोत

1

उसे दिखाएँ कि इकाई परीक्षण स्वयं बनाने से इकाई परीक्षण में कितनी मदद मिलती है।

जैसा कि सेंट फ्रांसिस ने एक बार कहा था, "प्रैच ऑलवेज। जब आवश्यक हो, शब्दों का उपयोग करें।"

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

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

— जॉर्ज स्टॉकर
स्रोत