यदि यूनिट परीक्षण इतना महान है, तो अधिक कंपनियां ऐसा क्यों नहीं कर रही हैं? [बन्द है]


103

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

मुझे इकाई परीक्षण याद है - यह जीवन को आसान बनाता है। लेकिन मुझे पता है कि जब मैं एक नई नौकरी की तलाश करता हूं, तो यूनिट परीक्षण या तो कुछ ऐसा होता है, जो कंपनियां भविष्य में "साथ चल रही होती हैं" या ऐसा कुछ करती हैं जो वे बिल्कुल नहीं करते (उह, यह थोड़ी देर के लिए रहा है अभी!)। मैं कहता हूँ कि पिछले 2 वर्षों में मैंने जो नौकरी की 60% -75% इकाइयाँ देखी हैं, वह इकाई परीक्षण को सूचीबद्ध नहीं किया है। मैं केवल एक या दो के बारे में सोच सकता हूं जिनके पास आवश्यकता के रूप में इकाई परीक्षण का अनुभव था (एक मध्य-स्तरीय डेवलपर स्थिति के लिए)।

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

संपादित करें: भले ही शीर्षक थोड़ा शैतान-अधिवक्ता है, मैं खुद को एक इकाई परीक्षण प्रस्तावक मानता हूं।


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

हाँ, मुझे शक है कि तुम सही हो। मेरा डोमेन आम तौर पर व्यापार के लाइन-ऑफ-ऐप है; अधर में किसी का जीवन नहीं। लेकिन कभी-कभी शेष राशि में कुछ बिलिंग, और यह महंगा हो सकता है।
जकॉल्म

11
कुर्सी परीक्षण: व्यक्ति कुर्सी पर बैठता है, आवेदन चलाता है, बग की रिपोर्ट करता है।
jcollum

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

1
@portfoliobuilder हाँ, आपके IDE के भीतर मानों की तुलना में वास्तव में कोड गुणवत्ता को बेहतर बनाने में मदद मिलेगी। क्योंकि राज्य हमेशा समान रहेगा, और कोड कभी नहीं बदलेगा। सही पर! और शुभकामनाएं।
फ्रांज डी।

जवाबों:


112

मेरे अनुभव में, इसमें शामिल कुछ कारक हैं:

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

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


हाँ, बहुत ज्यादा मेरे प्रबंधन का वर्णन किया है और हमारे पास कोई परीक्षण नहीं है।
टाइ।

और कुछ लोकप्रिय लैंगगेज (C / C ++) में इसके लिए समर्थन खराब है।
मार्टिन बेकेट

@ Mgb - CxxUnit मेरे लिए बहुत अच्छा काम करता है ...
डोमिनिक रॉजर

2
CxxTest बहुत अच्छा है। C ++ में खराब प्रतिबिंबन तंत्र के कारण, ऐसा लगता है कि वहाँ अधिक विविध "समाधान" प्रस्तुत किए गए हैं; CxxTest को बिल्ड सिस्टम में एक प्रीप्रोसेस स्टेप की आवश्यकता होती है, जबकि TUT जैसे टूल पूरी तरह से कंपाइल-टाइम और लैंग्वेज-समर्थित हैं, लेकिन उपयोग करने के लिए अजीब हैं।
टॉम

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

87

1) यह कठिन
2 है) इसमें
3 समय लगता है ) परीक्षण कोड के मूल्य को निर्धारित करना बहुत कठिन है

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


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

1
Esko, अच्छी कवरेज होने के अलावा, आपके पास अच्छे परीक्षण भी होने चाहिए जो वास्तव में किसी चीज़ का परीक्षण करते हैं। आपके पास 100% कोड कवरेज हो सकता है और वास्तव में बहुत कम परीक्षण हो सकता है
याकूब एडम्स

बहुत बढ़िया जवाब! आपने वही बात कही है जो बहुत कम शब्दों में मेरा जवाब है।
वेज

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

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

70

सारा दोष "प्रबंधन" पर लगाना आसान है। लेकिन प्रबंधन है वास्तव में आपको बता विशेष रूप से करने के लिए नहीं किसी भी इकाई परीक्षण करते हैं?

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

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

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

  • उपयोगकर्ता संपर्क। आपके एप्लिकेशन का आधा उपयोगकर्ता इंटरफ़ेस तर्क है। आप इसे स्वचालित तरीके से कैसे परीक्षण करते हैं, यदि आप एक बटन को स्थानांतरित नहीं करते हैं?
  • बाहरी एपीआई और रूपरेखा के साथ सहभागिता। यदि आप एक विंडोज कर्नेल ड्राइवर लिख रहे हैं, तो आप इसे कैसे परखेंगे? क्या आप हर IRP और कर्नेल फ़ंक्शन के लिए स्टब्स लिखते हैं, जो प्रभावी रूप से OS कर्नेल का अनुकरण बनाते हैं?
  • नेटवर्क संचार 21 वीं सदी की बात है। आप कई वितरित घटकों से मिलकर एक इकाई परीक्षण का समन्वय कैसे करते हैं?
  • आप अच्छे परीक्षा मामलों का चयन कैसे करते हैं? मैं आमतौर पर लोगों को "1000 पुनरावृत्तियों के पाश में यादृच्छिक चीजें करने की कोशिश करते हुए देखता हूं और देखता हूं कि क्या यह टूट जाता है" दृष्टिकोण। जब आप ऐसा करते हैं तो रिटर्न की तुलना में प्रयास अधिक होता है, महत्वपूर्ण कीड़े छूट जाते हैं, और यूनिट परीक्षण को छोड़ दिया जाता है।
  • आप कैसे परीक्षण करते हैं कि प्रदर्शन आवश्यकताओं को पूरा किया गया है?
  • परीक्षण में पैटर्न का ज्ञान दुर्लभ है: स्टब्स, डिब्बाबंद प्रतिक्रियाएं, प्रतिगमन परीक्षण ऐसी अवधारणाएं हैं जिन्हें ज्यादातर लोग नहीं जानते हैं। यूनिट टेस्टिंग के बारे में वास्तव में आपके कार्यस्थल में कितने लोग किताब पढ़ते हैं?

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

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


2
अच्छा विचार। लेकिन "उत्पाद" कोड बनाने के लिए यूनिट परीक्षणों को समय से अलग बनाने के लिए समय न निकालें!
जेफ कोटुला

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

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

1
Bochs या QEMU के साथ अपने कर्नेल ड्राइवर के लिए अपनी डिवाइस का अनुकरण लिखना संभव है।
ज़ेन लिंक्स

2
@floding, आकर्षक जवाब। मुझे लगता है कि मुझे यूनिट टेस्टिंग पर एक किताब पढ़ने के लिए जाना होगा।
डैन रोसेनस्टार्क

28

अधिकांश परीक्षण कुछ भी परीक्षण नहीं करते हैं।
यदि आप फ़ाइल मौजूद नहीं है और फ़ाइल मौजूद नहीं है, तो सफल नहीं होता है। महान! अब आपने जाँच की कि क्या यह BIG5 चीनी में फ़ाइल नाम के साथ काम करता है? NFS शेयर पर USB कुंजी पर फ़ाइल के साथ विस्टा पर और UAC चालू?

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

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


15
मुझे लगता है कि यह जवाब निशान को थोड़ा याद करता है। यूनिट टेस्टिंग और फंक्शनल टेस्टिंग, एक ही चीज नहीं और नहीं होनी चाहिए।
कील

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

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

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

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


15

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


12

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

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

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

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


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

11

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

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

संक्षेप में, हम TDD में विश्वास नहीं करते हैं, लेकिन हम यूनिट टेस्ट के लिए चाहेंगे। हमारे पास ऐसा करने का अनुभव नहीं है, और हम इसे आसानी से नहीं पा सकते हैं।


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

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

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

3
यह कैसे हो सकता है कि आप इकाई परीक्षण के लिए "सुनिश्चित नहीं हैं कि कैसे" लेकिन विश्वास करें कि टीडीडी रचनात्मकता और लचीलेपन को स्टंट करता है?
जोराकोरन

1
@ 6 साल पहले, यह जानना अच्छा होगा कि क्या आपने कभी यूनिट परीक्षण (या यहां तक ​​कि टीडीडी) शुरू किया है और क्या आप इसके बारे में जानते हैं।
ल्यूक पुप्लेट

11

वहाँ बहुत सारी कंपनियां हैं जो वास्तव में सर्वोत्तम प्रथाओं की तर्ज पर कुछ भी नहीं करती हैं। कोई कोड समीक्षा नहीं, कोई इकाई परीक्षण नहीं, कोई परीक्षण योजना नहीं, कुछ भी नहीं, बस अपनी पैंट की सीट से।

इसे एक निरंतर एकीकरण मंच का उपयोग करने और इकाई परीक्षणों को विकसित करने के लिए उन्हें एक अवसर के रूप में लें! एक ही समय में अपने कोड की गुणवत्ता और स्थिरता को बढ़ाने वाली शक्तियों को प्रभावित करने का आसान तरीका

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


मैं आमतौर पर ऐसी स्थिति में हूं जहां मेरे पास नीतिगत फैसलों पर शून्य प्रभाव है; मैं जूनियर सेनेटर हूँ जो कमेटी की कुर्सियों से उतारा जा रहा है।
ज्वलंत

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

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

6

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


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

6

इकाई परीक्षण कोड विकास वर्कफ़्लो का एक स्वाभाविक हिस्सा होना चाहिए, जिस तरह कंपाइलर है।

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

मेरा मानना ​​है कि यह आपके प्रश्न का उत्तर है "क्या गायब है और यूनिट परीक्षण करने वाली अधिक कंपनियां क्यों नहीं हैं" । :-)


1
+1 के लिए "कोड विकास वर्कफ़्लो का एक स्वाभाविक हिस्सा होना चाहिए"। प्रत्येक पेशेवर डेवलपर को आधिकारिक प्रक्रिया की परवाह किए बिना अपनी इकाई परीक्षण करना चाहिए । इस मुद्दे पर एकमात्र वैध तर्क एक इकाई की परिभाषा है ।
डंक

1
@ डंक यदि आप "यूनिट" को परिभाषित नहीं करते हैं, तो आप केवल यह कह रहे हैं कि "पेशेवर डेवलपर्स को अपना परीक्षण करना चाहिए"।
क्रिस डब्ल्यूडब्ल्यू

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

1
जब मैं कहता हूं कि एक इकाई की परिभाषा एक वैध तर्क है, तो मैं एक इकाई की ग्रैन्युलैरिटी के बारे में बात कर रहा हूं। क्या यह एक वर्ग है? क्या यह कक्षाओं का संग्रह है? क्या यह एक घटक है? मुझे लगता है कि क्लास लेवल यूनिट टेस्टिंग (कुछ अपवादों के साथ) की तुलना में अधिक लाभ होता है और इससे कई अर्थहीन परीक्षण होते हैं ...
Dunk

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

5

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


पृथ्वी पर आप अनुमान लगा सकते हैं कि बग को डिबग और फिक्स करने में कितना समय लगेगा। आम तौर पर डिबगिंग मेरे अनुभव से अधिक यादृच्छिक है - मुझे लगता है कि जहां समस्या है या मुझे नहीं पता है।
डोमिनिक रॉगर

1
हाँ, यही कारण है कि मैंने परीक्षण के लाभों को निर्धारित करने के लिए इसकी इतनी मेहनत की है।
ओवी टिसलर

5

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

उसके ऊपर, आप टीम का निर्माण करते हैं (या किसी को) बुनियादी ढांचे को रखने और उसे बनाए रखने की आवश्यकता होती है।

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


5

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


5

मुझे लगता है कि प्रोग्रामर को बस इसे करना शुरू करना है। शुरू करने के लिए कुछ सरल परीक्षणों को विकास के हिस्से के रूप में सही ठहराना आसान है।

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

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


4

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

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


4

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

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

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

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


3

मेरे अनुभव में यह वास्तव में आपके द्वारा लिखे जा रहे सॉफ़्टवेयर पर निर्भर करता है। मैंने पाया है कि UI के लिए यूनिट टेस्ट लिखना बेहद कठिन है। मैं केवल सिस्टम के कुछ हिस्सों के लिए यूनिट टेस्ट का उपयोग करता हूं, जिसमें एक निश्चित / बाहर है।


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

3

मुझे इकाई परीक्षण याद है - यह जीवन को आसान बनाता है।

यह सच नहीं है , एक कंपनी के लिए इकाई परीक्षण को अपनाने का पर्याप्त कारण है।

एक पर्याप्त कारण "सस्ता" (और / या, "बेहतर") हो सकता है: जो इकाई परीक्षण के बारे में साबित करना आसान नहीं है।

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

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


3

बेशक, आदर्श दुनिया में, आप एक इकाई परीक्षण होने के खिलाफ बहस नहीं कर सकते।

हालाँकि, क्या आप एक इकाई परीक्षण लिखते हैं, कई बातों पर निर्भर करता है:

  • सॉफ्टवेयर का उपयोग कैसे किया जाएगा। यदि आप सिर्फ अपने लिए सॉफ्टवेयर लिख रहे थे तो क्या आप यूनिट टेस्ट लिखेंगे? शायद ऩही। यदि आप व्यावसायिक रूप से बेचे जाने के लिए पूर्व-पैक सॉफ़्टवेयर लिख रहे थे, तो शायद हाँ।

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

  • कोड जटिलता: केवल परीक्षण कोड जिसे परीक्षण की आवश्यकता होती है। एक लाइन चर असाइनमेंट विधि को परीक्षण की आवश्यकता नहीं है। निष्पादन के कई रास्तों के साथ एक 50 लाइन विधि शायद।

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

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


3

मुख्य कारण यह है कि कई डेवलपर्स और विकास प्रबंधकों के पास कोई सुराग नहीं है कि यूनिट परीक्षण मौजूद हैं, या उनका उपयोग कैसे किया जाए।

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

तीसरा कारण है आलस्य और / या सस्तापन।


3

क्योंकि इकाई परीक्षण केवल उपयोगी होते हैं यदि आप परीक्षण योग्य कोड लिखते हैं। और टेस्ट करने योग्य कोड लिखना कठिन है। और लोग आलसी और / या सस्ते हैं।

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


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

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

2

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

मुद्दा यह है, हम केवल कॉल करने के लिए योग्य हैं (जो यह कहना नहीं है कि हम सभी को विषय पर समान ज्ञान है)। इसके अलावा, भले ही आपकी टीम नीति के मामले में इकाई परीक्षण (या नाम-योर-मेथड ऑफ-द-डे) नहीं करती है, इसका आमतौर पर मतलब यह नहीं है कि आप ऐसा नहीं कर सकते।

सच तो यह है, हम वास्तव में ROI को साबित नहीं कर सकते हैं, हम जो सामान करते हैं, उसमें से अधिकांश पर हम बारीकियों के लिए ठीक हैं। क्यों यूनिट परीक्षण को इस अनुचित / गैर-विशिष्ट मानक प्रमाण तक आयोजित किया जाता है, यह मेरे से परे है ...


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


2

मेरे 2 सेंट:

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

तो, यह सिर्फ समय की बात है।

मार्टिन-कोपलियन बहस है जिसमें बॉब मार्टिन दावा करते हैं कि:

"आजकल एक डेवलपर के लिए यह गैर-जिम्मेदाराना है कि वह कोड की एक पंक्ति को शिप करे जिसे उसने एक यूनिट टेस्ट में निष्पादित नहीं किया है।"

[ http://www.infoq.com/interviews/coplien-martin-tdd]


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

2

यदि आप सभी को परीक्षण पर बेचना चाहते हैं, तो निम्न कार्य करें:

  1. परीक्षणों का एक गुच्छा लिखें।
  2. अन्य डेवलपर जो कोड बदलते हैं और आपके परीक्षण को विफल करते हैं, उन्हें सूचित करें।
  3. वे अपना कोड ठीक कर लेंगे।
  4. अब आप उन विशेष बग के बिना जारी कर सकते हैं।

यहां तक ​​कि एक प्रबंधक भी यह समझ सकता था।


इकाई परीक्षण के कारण आपकी रिहाई बग मुक्त नहीं होगी। यह बग की संख्या को कम कर सकता है, लेकिन परीक्षण के कारण बग्स की संख्या को मापना / जोडना / मारना नहीं है, इसे मापना कठिन है।
टॉम

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

@jcollum हमेशा की तरह, यह लागत / लाभ अनुपात पर निर्भर करता है।
मात्रा_देव

2

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


2

अधिकांश अच्छे विचारों की तरह, गोद लेने का विचार की गुणवत्ता के साथ संगठनात्मक पथ निर्भरता के साथ अधिक है।

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

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

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

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


1

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


आपको ROI के बारे में लिंक पढ़ना चाहिए।
jcollum

1

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


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

प्रश्न: "क्यों अधिक कंपनियां [यूनिट परीक्षण] नहीं कर रही हैं?" A: "क्योंकि अधिकांश कंपनियां बेकार हैं।" मेरे लिए एक जवाब की तरह लगता है ...
रोजर लिप्सकॉम्ब
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.