क्या यूनिट परीक्षण वास्तव में उपयोगी हैं? [बन्द है]

Question

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

जैसा कि मैंने पहले ही उल्लेख किया है, मैं आमतौर पर ASP.NET वेब रूपों के साथ विकास कर रहा हूं, और हाल ही में मैं कुछ यूनिट परीक्षण लिखने के बारे में सोच रहा हूं। लेकिन मुझे इस बारे में कुछ सवाल मिले हैं।

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

तो प्रश्न संख्या 1: क्या ASP.NET वेब के लिए यूनिट परीक्षण लिखना कुछ ऐसा है जो अक्सर किया जाता है, और यदि यह है: मैं "गतिशील वातावरण" समस्या को कैसे हल करूं?

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

तो, सवाल नंबर 2: क्या आप लोग मुझे यूनिट टेस्ट लिखना शुरू करने की सलाह देंगे? मुझे लगता है कि यह वास्तविक कार्यान्वयन में मेरी मदद कर सकता है, लेकिन फिर मुझे लगता है कि यह मुझे धीमा कर सकता है।

Comments

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

— एडम

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

— जेफो जूल

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

— बिल के

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

— सालेके जुले

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

— nrr101

Answer 1

मेरी राय में: हाँ वे हैं, और हाँ आपको चाहिए।

1. वे आपको आपके द्वारा किए गए परिवर्तनों में विश्वास दिलाते हैं (बाकी सब अभी भी काम कर रहे हैं)। यह विश्वास है कि आपको कोड को ढालना क्या है, अन्यथा आप चीजों को बदलने से डर सकते हैं।

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

3. वे अन्य डेवलपर्स के लिए प्रलेखन के रूप में कार्य करते हैं कि आपका कोड कैसे काम करता है और इसका उपयोग कैसे किया जाता है।

आपके सामने पहली समस्या यह है कि ASP.NET अपने आप में इकाई परीक्षण लिखने में आपकी मदद नहीं करता है - वास्तव में यह आपके खिलाफ काम करता है। यदि आपके पास कोई विकल्प है, तो ASP.NET MVC का उपयोग करना शुरू करें , जो कि इकाई परीक्षण को ध्यान में रखकर बनाया गया था। यदि आप ASP.NET MVC का उपयोग नहीं कर सकते हैं, तो आपको ASP.NET में MVP पैटर्न का उपयोग करना चाहिए ताकि कम से कम आप अपने तर्क को आसानी से परख सकें।

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

मैं आपको अभ्यास करने और जोड़ी कार्यक्रम की सलाह दूंगा। पढ़ते वक्त:

• फुर्तीली सॉफ्टवेयर विकास, सिद्धांत, पैटर्न और अभ्यास [हार्डकवर]
• हेड फर्स्ट डिज़ाइन पैटर्न
• GOF डिज़ाइन पैटर्न बाइबिल
• रॉय ऑशेरोव का यूनिट टेस्टिंग से पहला परिचय
• इकाई परीक्षण पैटर्न बाइबिल

या, पहले अवलोकन के लिए:

• ठोस
• Xunit परीक्षण पैटर्न

Comments

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

— 19

यदि यूनिट-परीक्षण एक दस्तावेज के रूप में काम कर रहे हैं, तो कुछ गड़बड़ है। कोड की 500 लाइनों को पढ़ना यह समझने के लिए कि कोड की 5 लाइनें कैसे पीछे की ओर हैं।

— कोडर

@ कोडर: जब आप उच्च स्तरीय विधियों का परीक्षण करते हैं, तो इसमें कोड की 5 से अधिक लाइनें शामिल होती हैं।

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

— स्टेफानो बोरीनी जूल

@ कोडर: यह दस्तावेज नहीं करता है कि कोड क्या करता है, यह उस कोड में निहित मान्यताओं का दस्तावेजीकरण कर रहा है , अर्थात यह काम कब और क्यों करना है। यदि अंतर्निहित मान्यताओं को SUT में परिवर्तन द्वारा अमान्य कर दिया जाता है, तो एक या अधिक इकाई परीक्षण विफल हो जाने चाहिए। यह उच्च-स्तरीय डिज़ाइन / आर्किटेक्चर दस्तावेज़ीकरण या XML डॉक्स को प्रतिस्थापित नहीं करता है, लेकिन यह उन चीज़ों को कवर करता है जो कभी नहीं कर सकते।

— एरोन

Answer 2

नहीं।

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

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

Djikstra ने 1988 में परीक्षण-के-सबूत-के-सही होने के तरीके की अवधारणा को तोड़ दिया , और उन्होंने जो लिखा वह आज भी केवल मान्य है:

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

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

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

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

Comments

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

— स्टेफानो बोरीनी

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

— ब्रायन ओकले

> but if the test itself is buggy, then you have false confidenceऔर यदि मैन्युअल परीक्षक अपना काम सही तरीके से नहीं करता है, तो आपको भी गलत विश्वास है।

— स्टेफानो बोरीनी

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

— ब्रायन ओकली

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

— तेलस्तीन

Answer 3

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

अपने स्थानीय वेब सर्वर को शुरू करने, प्रश्न में पृष्ठ पर ब्राउज़ करने, डेटा दर्ज करने या उचित परीक्षण के बीज तक इनपुट सेट करने, फ़ॉर्म सबमिट करने और परिणामों का विश्लेषण करने ... कोड के निर्माण के ओवरहेड की भी कल्पना करें ... निर्माण और मार nUnit रन बटन।

यहाँ एक मजेदार छवि भी है ...

मुझे यह छवि यहां मिली:
http://www.howtogeek.com/102420/geeks-versus-non-geeks-when-doing-repetitive-tasks-funny-chart/

Comments

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

— हीथ लिली

प्यारा ग्राफिक, लेकिन यह पैमाने पर बुरी तरह से गलत है। जैसा कि मैंने अपने जवाब में बताया, SQLite की पूर्ण परीक्षण कवरेज के लिए उत्पाद में वास्तविक कोड की तुलना में परीक्षणों में लगभग 1200x अधिक कोड की आवश्यकता होती है। और अगर आप नहीं कर रहे हैं कि पूर्ण कवरेज के बारे में जुनूनी, आप अभी भी उत्पाद की तुलना में कई गुना अधिक परीक्षण की जरूरत है यहां तक कि अपने परीक्षण में कवरेज के किसी भी उपयोगी स्तर दृष्टिकोण। यहां सटीक होने के लिए, उस लाल रेखा के ऊर्ध्वाधर भाग को लगभग 3 पृष्ठ की लंबाई के लिए ऊपर और ऊपर बढ़ते रहना होगा।

— मेसन व्हीलर

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

— Aatch

@MasonWheeler आप ज़ेनो के विरोधाभासों में से पहले पर असफल हो रहे हैं । यदि आप इस छवि को SQLite के परीक्षण के स्तर तक स्केल करना चाहते हैं, तो X- अक्ष को भी अपनी वर्तमान लंबाई के 100 गुना जैसे कुछ का विस्तार करना होगा।

— इज़काता

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

— वरुण अचर

Answer 4

यूनिट परीक्षण में इन दिनों इसके बारे में कुछ रहस्य है। लोग इसे ऐसे मानते हैं जैसे कि 100% परीक्षण कवरेज एक पवित्र कब्र है, और मानो इकाई परीक्षण विकासशील सॉफ्टवेयर का एक सही तरीका है।

वे बात याद कर रहे हैं।

यूनिट टेस्टिंग इसका जवाब नहीं है। परीक्षण है

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

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

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

दूसरी ओर, मशीनें थकाऊ और समय लेने वाले कार्यों को करने में उत्कृष्ट हैं। कंप्यूटर का आविष्कार आखिर किसलिए किया गया था।

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

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

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

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

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

TL; DR: यूनिट परीक्षण के बारे में अभी चिंता मत करो । बस पहले अपने सॉफ़्टवेयर के परीक्षण के बारे में चिंता करें।

Comments

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

— सीन ओसवा

Answer 5

निर्भर करता है

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

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

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

Comments

यह लाभप्रद है। आपको यह जानना होगा कि अच्छे परीक्षण कैसे लिखें जो SUT के मूल्य को पकड़ते हैं।

— एंडी

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

— ब्रेंडन लॉन्ग

Answer 6

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

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

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

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

और पिछले नहीं बल्कि कम से कम, ब्रायन द्वारा टिप्पणी जो मुझे लगता है कि पूरे मामले में नाखून हैं:

(...) वे आपके आत्मविश्वास को बढ़ाते हैं (या चाहिए ...) कि कोड वह करता है जो आपने इसे करने के लिए डिज़ाइन किया था, और आज जो वह करता है उसे कल करना जारी रखता है।

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

_{* वे धीरे-धीरे अपने कोड आधार पर अधिक से अधिक परीक्षण शुरू करते हैं, लेकिन हम सभी जानते हैं कि यह सामान आमतौर पर कैसा दिखता है।}

Comments

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

— ZJR

Answer 7

ASP.NET के लिए इकाई परीक्षण लिख रहा है। कुछ ऐसा है जो अक्सर किया जाता है, और यदि यह है: मैं "गतिशील वातावरण" समस्या को कैसे हल करूं?

यह अक्सर नहीं किया जाता है। UI तत्वों के साथ कार्य करना वैसा नहीं है, जिस पर यूनिट परीक्षण अच्छे होते हैं, क्योंकि प्रोग्राम को सही तरीके से सत्यापित करने का कोई शानदार तरीका नहीं है कि सही चीजें सही स्थानों पर स्क्रीन पर समाप्त होती हैं।

क्या आप लोग मुझे यूनिट टेस्ट लिखने की सलाह देंगे? मुझे लगता है कि यह वास्तविक कार्यान्वयन में मेरी मदद कर सकता है, लेकिन फिर मुझे लगता है कि यह मुझे धीमा कर सकता है।

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

एक बात का ध्यान रखें कि वे आमतौर पर आपको धीमा कर देंगे।

यह ठीक हैं।

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

Comments

प्रश्न के उपयोग के मामले का वास्तव में जवाब देने के लिए +1! बाकी सभी "यूनिट टेस्ट" भाग पर कूद गए और "ASP.NET वेब फॉर्म" भाग के बारे में भूल गए ...

— इज़्काटा

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

— मंटोरोक

Answer 8

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

ऐसा इसलिए है क्योंकि आपने कभी बड़ा प्रोग्राम नहीं किया है।

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

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

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

एक मॉक क्लास के साथ डेटाबेस एक्सेस का मज़ाक उड़ाएँ जो मॉडल क्लास को अच्छी तरह से परिभाषित, हार्डकोड डेटा से भरा हो। या , फिक्सेशन डेटा के साथ एक परीक्षण डेटाबेस भरें और वहां से काम करें।

-क्या आप लोग मुझे यूनिट टेस्ट लिखना शुरू करने की सलाह देंगे?

अरे हाँ। पहले बेक के "टेस्ट ड्रिवेन डेवलपमेंट" को पढ़ें ।

मुझे लगता है कि यह वास्तविक कार्यान्वयन में मेरी मदद कर सकता है, लेकिन फिर मुझे लगता है कि यह मुझे धीमा कर सकता है।

यह अब आपको धीमा कर देता है। लेकिन जब आपको दिनों के बजाय घंटों बहस करना पड़ता है, तो आप अपना विचार बदल देंगे।

किसी भी सलाह की सराहना की जाएगी :)

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

Answer 9

संपादित करें: मैं बेशक TDD समर्थक / con dogpile और स्किप किए गए प्रश्न # 1 में शामिल हुआ:

1 - ASP.net वेबफॉर्म में इकाई परीक्षण लागू करना:

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

2 - पहले स्थान पर इकाई परीक्षण सार्थक हैं या नहीं:

ठीक है, पूर्ण-प्रकटीकरण:

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

हालाँकि,

• मैं ज्यादातर क्लाइंट-साइड वेब के लिए लिखता हूं और वहां का वास्तविक प्रोग्रामिंग हिस्सा गतिशील टाइपिंग, प्रथम श्रेणी के कार्यों और ऑब्जेक्ट म्यूटेबिलिटी के संबंध में सबसे तेज और ढीली भाषाओं में से एक में है।

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

तो हाँ, वहाँ कुछ अवसरों के लिए बहुत सारे हैं यहाँ और वहाँ विफलताओं का एक बड़ा झरना बनाने के लिए अगर आपके डिजाइन कौशल पूरा बकवास हैं या आप 1-2 गुणवत्ता देव समस्याओं में बड़ी मात्रा में औसत दर्जे के देवता फेंक रहे हैं।

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

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

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

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

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

Comments

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

— फिजेटीया

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

— एरिक रेपेन

Answer 10

मेरे अनुभव में, यूनिट परीक्षण वास्तव में बहुत उपयोगी होते हैं, जब आप उनके साथ शुरू करते हैं और उनके साथ रहते हैं अर्थात टेस्ट-प्रेरित विकास। यहाँ पर क्यों:

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

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

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

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

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

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

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

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

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

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

अब, सभी ने कहा कि इकाई परीक्षण के नुकसान हैं:

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

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

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

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

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

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

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

Answer 11

सही ढंग से उपयोग किए जाने पर यूनिट परीक्षण उपयोगी होते हैं; आपके तर्क के साथ विभिन्न समस्याएं हैं।

"जब मैं विकसित कर रहा हूं तो मैं बहुत परीक्षण और त्रुटि से गुजरता हूं" केविन ने कहा।

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

s writing unit tests for ASP.NET web forms something that is done often

मुझे यह कहने के लिए सांख्यिकीय आंकड़ों का कोई ज्ञान नहीं है कि लोग कितनी बार वेब प्रपत्रों का परीक्षण करते हैं। यह मायने नहीं रखता। UI परीक्षण करने के लिए कठिन है और यूनिट टेस्ट को UI पर युग्मित नहीं किया जाना चाहिए। अपने तर्क को परतों, वर्ग पुस्तकालयों में अलग करें जिन्हें परीक्षण किया जा सकता है। बैक-एंड लॉजिक से अलग से UI का परीक्षण करें।

So, question number 2: Would you guys advise me to start writing unit tests?

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

Comments

वहाँ बाहर परीक्षण चौखटे हैं कि aspx पृष्ठों पर परीक्षण करने के लिए बस परीक्षण कर सकते हैं अगर पृष्ठों को सफलतापूर्वक अलग परिदृश्यों में लोड होता है या नहीं। यह काफी अच्छा नहीं हो सकता है, लेकिन यह कुछ भी नहीं से बेहतर है।

— विस्मयकारी

Answer 12

एक व्यावहारिक स्तर पर यूनिट परीक्षण एक बहुत महत्वपूर्ण कारण के लिए बेहद उपयोगी हो सकते हैं: आप एक बार में एक कोड का एक सा परीक्षण कर सकते हैं।

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

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

यूनिट टेस्ट का मतलब फ्रंट-एंड का परीक्षण करना नहीं है : एक यूनिट टेस्ट के बारे में सोचें जो आप लिख रहे हैं या किसी नई विधि का परीक्षण करने के लिए बनाते हैं, न कि किसी प्रकार की स्थिति के लिए जिसे आपके कोड को पूरा करने की आवश्यकता होती है।

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

Comments

"इकाई परीक्षण फ्रंट-एंड्स का परीक्षण करने के लिए नहीं हैं" कौन कहता है? मैं इस पर सवाल नहीं उठा रहा हूं। मैं सिर्फ यह जानना चाहूंगा क्योंकि बहुत से लोगों को यह गलत विचार लगता है और मैं चाहूंगा कि वे उनके साथ थॉट-नॉट-व्हाट-प्रभावशाली-टीडीडी-एडवोकेट-सोर्स-स्टिक कहते हैं।

— एरिक रेपेन

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

— तजार्ट

Answer 13

एक चीज जिस पर छुआ नहीं जाता है वह विभिन्न प्रकार के कोड के परीक्षण की जटिलता है।

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

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

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

Answer 14

ASP.NET वेब प्रपत्रों के लिए इकाई परीक्षण लिखना आम बात नहीं है और इसे पूरा करना बहुत कठिन है। हालांकि, इसका मतलब यह नहीं है कि परियोजना को इसे छोड़ देना चाहिए।

यूनिट परीक्षण corner stonesमिशन महत्वपूर्ण अनुप्रयोगों के हैं और वे विश्वसनीयता और मन की शांति प्रदान करते हैं जो कोर कार्यक्षमता अपेक्षित रूप से करती है।

दरअसल आप ASP.NET MVP पैटर्न के साथ यूनिट टेस्टिंग को बहुत आसान बना सकते हैं जो आपके वेब फॉर्म डेवलपमेंट में इस्तेमाल किया जा सकता है। यह चिंताओं और की जुदाई का परिचय देंगे ability to write essential unit tests।

कुछ संदर्भ जो देखने में मददगार हो सकते हैं, वे हैं:

• ASP.NET वेबफॉर्म एप्लिकेशन (MVP पैटर्न) के परीक्षण के साथ शुरुआत करना
• ASP.NET वेब प्रपत्र MVP के साथ रीडायरेक्ट करना और परीक्षण करना
• ASP.NET के साथ मॉडल दृश्य प्रस्तुतकर्ता - CodeProject

Comments

+1 यह मायने नहीं रखता है कि आप यूनिट टेस्ट कर रहे हैं या नहीं, एमवीपी वेब फॉर्म के साथ काम करने का तरीका है (शायद विनफॉरम भी)।

— सिमोरमन

Answer 15

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

Comments

बिना किसी डर के सुरक्षा की झूठी भावना है।

— कोडर

शायद "कम डर" एक बेहतर वाक्यांश है, लेकिन जवाब अभी भी काफी हद तक सही है।

— ब्रेंडन लॉन्ग

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

— m3th0dman

Answer 16

यह मेरा अनुभव है कि हां , यूनिट परीक्षण उपयोगी हैं।

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

यूनिट परीक्षण विभिन्न लाभ देता है:

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

इसके अतिरिक्त, यह सुनिश्चित करता है कि इकाइयां आपके, डेवलपर के कार्य को जारी रखें, सोचा कि उन्हें काम करना चाहिए। सॉफ्टवेयर में परिवर्तन होता है, और यह अप्रत्याशित तरीकों से इकाइयों को प्रभावित कर सकता है।

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

हालाँकि...

इकाई परीक्षण परीक्षण का अंत नहीं है। अन्य प्रकार के परीक्षण अभी भी आवश्यक हैं। उदाहरण के लिए, जब आपने दिखाया है कि इकाइयाँ उस तरह से काम करती हैं जिस तरह से आप उनसे काम करने की उम्मीद करते हैं, तब भी आपको यह दिखाने की ज़रूरत है कि प्रत्येक इकाई उस तरह से काम करती है जिस तरह से बात करने वाली इकाइयाँ काम करने की उम्मीद करती हैं। यही है, क्या आपके घटक एक-दूसरे के साथ सही ढंग से एकीकृत होते हैं?

Answer 17

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

बड़े एप्लिकेशन के लिए जहां ओटी को प्राप्त करने के लिए आपके द्वारा परीक्षण किए जा रहे पृष्ठ को प्राप्त करने के लिए 30 के नेविगेशन की आवश्यकता होती है, यह बहुत महंगा है।

Answer 18

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

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

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

यह एक डायजेस्कट्रियन तर्क है: यूनिट टेस्ट केवल एक प्रोग्राम के खिलाफ निष्पादित किया जा सकता है जो कि चलाने के लिए पर्याप्त विस्तृत है।

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

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

आपको यह जानना होगा कि 10 + -5 कक्षाएँ क्या हैं या आप अभी क्या करते हैं, और कई दृष्टिकोणों से अपने कोड की जांच करने में सक्षम हो सकते हैं, प्रत्येक चित्र जो आप देख रहे हैं, और आप हजारों बगों को मार देंगे। कागजों पर।

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

वहाँ बस इतना आसान है ...

इसके अलावा, मुझे पता चला कि मेरे एप्लिकेशन अधिक उपयोग करने योग्य हैं, अगर वे सीधे उपयोग के मामलों से आते हैं ... यदि उपयोग के मामलों को अच्छी तरह से लिखा जाता है (ACTOR क्रिया विषय, रखरखावकर्ता कैश मशीन खोलने का अनुरोध करता है) ...

मैंने 95 +% कोड कवरेज के साथ कोड किया है। बेशक, मैं कभी-कभी ईकाई परीक्षण करता हूं। गणना में सीमा की जाँच के लिए, लेकिन मैं अभी तक गंभीर प्रतिगमन (गंभीर: 24 घंटों में मिटा नहीं पाता) को पूरा करने के लिए भी यूनिट परीक्षणों का उपयोग नहीं करता हूं।

कभी-कभी मैं 3-4 दिनों के लिए कोड की एक भी लाइन सीधे नहीं करता, बस ड्राइंग करता हूं। फिर, एक दिन में, मैं 1500-2000 पंक्तियों में टाइप करता हूं। अगले दिन तक, वे ज्यादातर उत्पादन के लिए तैयार हैं। कभी-कभी इकाई परीक्षण (80 +% कवरेज के साथ) लिखे जाते हैं, कभी-कभी (इसके अलावा) परीक्षकों को इसे तोड़ने की कोशिश करने के लिए कहा जाता है, हर बार, कुछ लोगों को इसे देखकर इसकी समीक्षा करने के लिए कहा जाता है।

मैं अभी तक उन यूनिट परीक्षणों को कुछ भी देख रहा हूं।

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

Comments

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

— एरिक रेपेन

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

— आदम जूल