इकाई परीक्षण या परीक्षण संचालित विकास सार्थक है?

Question

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

ऐसा लगता है कि लेखन परीक्षण अतिरिक्त काम है, लोगों को वास्तविक कोड लिखने पर एक बैसाखी देता है, और बहुत बार प्रभावी नहीं हो सकता है।

मैं समझता हूं कि यूनिट परीक्षण कैसे काम करते हैं और उन्हें कैसे लिखना है, लेकिन क्या कोई ऐसा बना सकता है कि यह वास्तव में एक अच्छा विचार है और प्रयास और समय के लायक है?

इसके अलावा, क्या ऐसा कुछ है जो TDD विशेष रूप से स्क्रम के लिए अच्छा है?

Comments

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

— दाऊद इब्न करीम

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

— मार्जन वेनमा

"असली कोड लिखने पर लोगों को बैसाखी देता है"? क्या इस तरह से सबसे अच्छी प्रथाओं का वर्णन नहीं किया जा सकता है?

— user16764

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

— कोडर

@NimChimpsky: मुझे TDD के प्रति कोई नकारात्मकता नहीं है, मैं सिर्फ प्रचार का पालन नहीं कर रहा हूँ। इसके सकारात्मक पक्ष हैं, और नकारात्मक भी। सुरक्षा का गलत बोध उनमें से एक है।

— कोडर

Answer 1

संक्षिप्त उत्तर: बिल्कुल सकारात्मक।

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

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

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

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

Comments

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

— TC1

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

— निमचिम्प्सकी

+1 के लिए "हम आम तौर पर उन लोगों को किराए पर नहीं लेते हैं जो नियमित रूप से अपने काम के हिस्से के रूप में यूनिट परीक्षण नहीं बनाते हैं"। मुझे हाल ही में एक उम्मीदवार को अस्वीकार करना पड़ा, जिसने अन्य कमियों के बीच दृढ़ता से घोषणा की कि वह स्वत: परीक्षण लिखना पसंद नहीं करता है क्योंकि वे समय की बर्बादी कर रहे हैं और वह स्वयं कोड का परीक्षण कर सकता है।

— ftr

आप साबित नहीं कर सकते कि एक स्वचालित कोड का उपयोग करके किसी भी प्रासंगिक तरीके से एक nontrivial कोड काम करता है। स्वचालित परीक्षणों के साथ, आप केवल यह साबित कर सकते हैं कि कोड परीक्षणों को पास करता है - यदि परीक्षण आपके उपयोग के मामलों का 100% कवर करते हैं, तो आपके पास शायद "निश्चित स्तर" है, लेकिन इसका मतलब यह नहीं है कि कोड "साबित काम करता है"। वास्तविक उकसावे के लिए, आपको en.wikipedia.org/wiki/Formal_verification की आवश्यकता होगी - जैसे, आप यहाँ "गलत" शब्द का प्रयोग कर रहे हैं।

— vaxquis ऑक्ट

@vaxquis Yes, आप शब्द प्रमाण के उपयोग के बारे में सख्ती से सही हैं। लेकिन मैं चाहूंगा कि परीक्षणों की अनुपस्थिति की तुलना में परीक्षणों की उपस्थिति (या टीडीडी का अभ्यास) एक कार्य प्रणाली का बेहतर सबूत है।

— रुपये

Answer 2

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

छवि स्रोत

Comments

पारंपरिक से आपका क्या अभिप्राय है ? कुछ भी जो टीडीडी नहीं है?

— जियोर्जियो

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

— डॉक ब्राउन

Answer 3

यूनिट परीक्षण या परीक्षण संचालित विकास के लायक है?

हाँ, यह करता है । अंकल बॉब (रॉबर्ट सी मार्टिन) ने एक प्रस्तुति में बताया;

एक डेवलपर के लिए यह साबित करने के लिए कि उसका कोड परीक्षण लिखने और उसके बारे में चिल्लाने, गाने या नृत्य करने से बेहतर है।

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

इस पर बहुत सारे सामान लिखे हैं,

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

क्या SCRUM, यूनिट परीक्षण और TDD संबंधित हैं?

शीघ्र ही, जब आप एक मास्टर Unit testingहोंगे तो आप के पास होंगे TDD। SCRUM का इससे कोई लेना-देना नहीं है, लेकिन जैसा कि वे कहते हैं, महान चीजें अच्छी तरह से मिश्रित होती हैं, सॉफ़्टवेयर विकसित करने की ये तकनीक एक उत्कृष्ट स्टैक में जुड़ जाती है , अगर आपने इसे आज़माया नहीं है तो इसे आज़माएं।

क्या ऐसा कुछ है जो TDD विशेष रूप से SCRUM के लिए अच्छा है?

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

Answer 4

ऐसा लगता है कि लेखन परीक्षण अतिरिक्त काम है, लोगों को वास्तविक कोड लिखने पर एक बैसाखी देता है, और बहुत बार प्रभावी नहीं हो सकता है।

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

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

मैं समझता हूं कि यूनिट परीक्षण कैसे काम करते हैं और उन्हें कैसे लिखना है, लेकिन क्या कोई ऐसा बना सकता है कि यह वास्तव में एक अच्छा विचार है और प्रयास और समय के लायक है?

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

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

इसके अलावा, क्या ऐसा कुछ है जो TDD विशेष रूप से SCRUM के लिए अच्छा है?

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

Answer 5

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

यूनिट परीक्षण के मेरे कारणों में शामिल हैं:

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

आपको प्रगति की भावना देता है।

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

प्रलेखन की एक अतिरिक्त परत प्रदान करता है (खासकर यदि आप अपने परीक्षणों को ठीक से टिप्पणी करते हैं)।

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

इस धागे में अन्य पदों के साथ-साथ अन्य भी शामिल हैं। ये इसके लायक है।

Answer 6

इकाई परीक्षण या परीक्षण संचालित विकास सार्थक है?

निश्चित रूप से हाँ (अन्य उत्तर देखें)

[क्या यह] वास्तव में एक अच्छा विचार है और प्रयास और समय के लायक है?

• हां यदि आप कुछ नया शुरू करते हैं (एक नया मॉड्यूल या पूरी तरह से नया एप्लिकेशन जोड़ें)
• नहीं, यदि पहले से ही बहुत सारे मौजूदा कोड हैं जो परीक्षण-संचालित नहीं थे और जिन्हें विस्तारित (विरासत) किया जाना चाहिए।

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

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

यदि आप TDD करते हैं तो कोड स्वचालित रूप से आसान परीक्षण योग्य है।

Answer 7

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

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

अब मान लें कि यह चरवाहा दृष्टिकोण वर्षों तक चलता है? अब हर परिवर्तन, यहां तक ​​कि तुच्छ लोगों को, एक नई अनसुनी समस्याओं का बुलबुला लगता है। इतना ही नहीं, लेकिन बहुत सी चीजें जिन्हें आप करना चाहते हैं, ताकि आप काम को बेहतर बना सकें, आप ऐसा नहीं कर सकते क्योंकि वे बहुत जोखिम भरी या बहुत महंगी या दोनों हैं। तो आप पैच को सिस्टम पर ज्यादा से ज्यादा कंफर्टेबल और बुग्जियर बनाते हैं और इस्तेमाल करने में सख्त होते हैं।

उपयोगकर्ता आपके समय के अनुमानों पर सवाल उठाना शुरू कर देते हैं क्योंकि वे बड़े और बड़े होते रहते हैं और उन्हें यह समझाना मुश्किल है कि सिस्टम इतना जटिल गड़बड़ हो गया है, यह पता लगाना मुश्किल है कि बदलाव कहां करना है और अभी भी यह सुनिश्चित करना मुश्किल है कि वे डॉन न हों ' t कुछ और तोड़ो।

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

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

Answer 8

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

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

TDD के लिए लाल-हरे-परावर्तक दृष्टिकोण के लिए, मुझे लगता है कि थोड़ा थकाऊ। लेकिन प्रत्येक उसके अपने के लिए।

Comments

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

— रॉबिंस

Answer 9

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

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

वास्तव में एक प्रकार का परीक्षण है जो मैंने पाया है आमतौर पर स्वीकार किया जाता है और मेरा मानना ​​है कि अंततः बेकार है। नामी जीयूआई आधारित परीक्षण जैसे सेलेनियम, वेबड्राइवर, वियर या आर्क्विलियन का उपयोग करके। इस तरह से मुझे मेरे TDD प्रोजेक्ट्स पर 5 मिनट के निर्माण चक्रों के बजाय 7 घंटे के निर्माण चक्र मिलते हैं।

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

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

तो, आपके पास एक विकल्प है। आप टीडीडी का अभ्यास करके डिजाइन और डॉक्यूमेंटेशन कर सकते हैं जो कि मेरे 10 साल के विकास के अनुभव के आधार पर इस तरह के डॉक्यूमेंटेशन को बनाने के लिए एकमात्र ज्ञात और सिद्ध विधि है। या आप राजनीति में जा सकते हैं।

Comments

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

— gbjbaanb

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

— क्रिश

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

— k3b

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

— मुहम्मद