इकाई परीक्षण न करना कब उचित है?

138

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

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

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

इसलिए मैं हर बार एक ही निष्कर्ष पर पहुंचता हूं। निवेश पर रिटर्न बहुत कम है।

मैंने कभी-कभी कुछ परीक्षण सेट किए हैं यह सुनिश्चित करने के लिए कि मैंने एक एल्गोरिथ्म को सही ढंग से लिखा है, जैसे कि किसी व्यक्ति की कंपनी की किराया तिथि के आधार पर वर्षों की संख्या की गणना करना। लेकिन एक कोड-कवरेज के दृष्टिकोण से मैंने अपने कोड का लगभग 1% कवर किया है।

मेरी स्थिति में, क्या आपको अभी भी इकाई परीक्षण को एक नियमित अभ्यास बनाने का एक तरीका मिलेगा, या क्या मैं उस ओवरहेड से बचने के लिए उचित हूं?

अद्यतन: मेरी स्थिति के बारे में कुछ चीजें जो मैंने छोड़ी हैं: मेरी परियोजनाएं सभी वेब अनुप्रयोग हैं। अपने सभी कोड को कवर करने के लिए, मुझे स्वचालित UI परीक्षण का उपयोग करना होगा, और यह एक ऐसा क्षेत्र है जहां मुझे अभी भी मैनुअल परीक्षण पर बहुत अच्छा लाभ नहीं दिखता है।

unit-testing tdd

— केन पेसिसा
स्रोत

1

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

— केन पेसिसा

1

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

— जॉन कास्टर

2

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

— ओ'रोनी

1

यह वास्तव में एक जवाब नहीं है, सिर्फ एक अवलोकन है ... इकाई-परीक्षण के खिलाफ आपका तर्क क्योंकि "आवश्यकताएं बहुत बार बदलती हैं" मुझे उल्टे तर्क की याद दिलाती हैं जहां मैं सुनता हूं कि मैं कहां काम करता हूं: "हमारे कार्यक्रम बहुत स्थिर हैं, परीक्षण का क्या मतलब है यह लगभग वैसे भी कभी नहीं बदलता है! " ;)

— बैन

2

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

— न्यामिउ द गैलेनथ्रोपे

84

बहुत सारे उदाहरण मैंने परीक्षण के देखे हैं जो कोड के सभी पहलुओं को कवर करते हुए, minutiae में उतर जाते हैं।

इसलिए? आपको हर चीज का परीक्षण नहीं करना है । बस प्रासंगिक बातें।

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

यह वास्तव में गलत है। यह अधिक कुशल नहीं है। यह वास्तव में सिर्फ एक आदत है।

अन्य सोलो डेवलपर्स जो करते हैं वह स्केच या रूपरेखा लिखता है, परीक्षण के मामलों को लिखता है और फिर अंतिम कोड के साथ रूपरेखा को भरता है।

यह बहुत, बहुत कुशल है।

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

वह भी झूठा है। परीक्षण खींचें नहीं हैं। आवश्यकताओं में परिवर्तन ड्रैग है।

आवश्यकताओं को प्रतिबिंबित करने के लिए आपको परीक्षणों को ठीक करना होगा। चाहे उनका माइनुटिया हो, या हाई-लेवल; पहले लिखा या आखिरी लिखा।

कोड तब तक नहीं किया जाता जब तक कि परीक्षण पास न हो जाएं। यह सॉफ्टवेयर का एक सार्वभौमिक सत्य है।

आपके पास एक सीमित "यहां यह" स्वीकृति परीक्षण हो सकता है।

या आपके पास कुछ यूनिट परीक्षण हो सकते हैं।

या आपके पास दोनों हो सकते हैं।

लेकिन कोई फर्क नहीं पड़ता कि आप क्या करते हैं, हमेशा यह प्रदर्शित करने के लिए एक परीक्षण होता है कि सॉफ्टवेयर काम करता है।

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

— S.Lott
स्रोत

8

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

— केन प्रीस्पिसा

9

@ केन पेसिसा: क्षमा करें। मैंने लगभग दो साल पहले (परीक्षण के अंतिम 30 वर्षों के बाद) टीडीडी कूल-एड पिया था। अब मैं टेस्ट-प्रथम पर अटक गया हूं। इसने मुझे बहुत अधिक, बहुत अधिक उत्पादक बना दिया क्योंकि भवन बनाते समय मेरी सोच कम है।

— एस.लॉट

3

@ केन पेसिसा: नहीं, जवाब में संतुलन है। यदि आपसे पूछा जाए कि क्या शून्य से विभाजित करना सही है, तो आपको एक कारण के लिए एक तरह से झुकाव प्रतिक्रियाएं मिलेंगी। यदि आपसे पूछा जाए कि क्या sqrt(-1)पूर्णांक होना चाहिए, तो आपको एक तरह से झुककर प्रतिक्रियाएं मिलेंगी। शेष राशि "कैसे" और "किस क्रम" के आसपास है। नंगे तथ्य यह है कि आपको परीक्षण करना चाहिए । इसलिए पहले परीक्षण लिखें और सुनिश्चित करें कि वे काम करते हैं।

— S.Lott

21

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

— बिलथोर

10

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

— वेक्टर

107

कल्पना कीजिए कि आपके पास एक परीक्षण का एक सूट था जो एक आईबॉल में चल सकता था और एक हरे या लाल प्रकाश को रोशन करेगा। कल्पना कीजिए कि परीक्षणों के इस सूट ने सब कुछ परीक्षण किया ! कल्पना कीजिए कि आप सभी को परीक्षण के सूट को चलाने के लिए ^ T टाइप करना था। इससे आपको क्या शक्ति मिलेगी?

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

हाँ, आप उन सभी चीजों को कर सकते हैं! और समय के साथ आपके कोड का क्या होगा? यह क्लीनर और क्लीनर मिल जाएगा क्योंकि इसे साफ करने के लिए कोई जोखिम नहीं होगा।

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

आपको लगता है कि आप कितना डिबगिंग करेंगे?

यदि यह कल्पना की तरह लगता है, तो आप सही हैं। लेकिन वास्तविकता बहुत अलग नहीं है। कुछ सेकंड, और TDD अनुशासन के साथ परी के साथ नेत्रगोलक को बदलें, और आपको बहुत पसंद आया है।

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

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

— चाचा बॉब।
स्रोत

28

वाह, अंकल बॉब? यहां अपने विचार प्राप्त करना बहुत अच्छा है। मैं आपके साथ TDD के लाभों पर सहमत हूं, वास्तव में वहाँ होने का कोई तर्क नहीं है। सवाल समय और आरओआई के निवेश के बारे में है। इन बातों पर विचार करना मेरे लिए मूर्खतापूर्ण नहीं है। कल्पना कीजिए कि एक परियोजना के बिना मुझे TDD के साथ समाप्त करने के लिए 50% अधिक समय लगेगा, और परी मुझे बताती है कि यह मुझे परियोजना के जीवनकाल में मैनुअल परीक्षण से केवल 10% समय बचाएगा। यह एक कल्पना की तरह लग सकता है, लेकिन मैं इसे कुछ परियोजनाओं के साथ पूरी तरह से प्रशंसनीय के रूप में देखता हूं।

— केन प्रीस्पिसा

11

@Ken "बिना किसी प्रोजेक्ट के मुझे TDD के साथ खत्म होने में 50% अधिक समय लगेगा"। यह बिल्कुल मेरे लिए कल्पना की तरह लगता है। वास्तव में, ऐसा लगता है कि आपने इसे समर्थन करने के लिए सबूतों के एक टुकड़े के बिना मौके पर ही बना दिया।

— रीन हेनरिक्स

18

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

— केन प्रीस्पा

11

@ सच, क्या "उपलब्ध सबूत है?" कृपया विस्तार से बताएं।

— केन पेसिसा

22

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

— जियोर्जियो

34

आप जो गलती कर रहे हैं, वह यह है कि आप समय निवेश के रूप में परीक्षण कर रहे हैं, जिसमें तत्काल रिटर्न नहीं है। यह जरूरी नहीं कि इस तरह काम करे।

सबसे पहले लेखन परीक्षण वास्तव में आपको इस पर ध्यान केंद्रित करते हैं कि आपके कोड के इस हिस्से को क्या करना है।

दूसरे उन्हें चलाने से बग का पता चलता है जो अन्यथा परीक्षण में सामने आएगा।

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

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

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

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

— glenatron
स्रोत

2

@, परीक्षण सूट एक निष्पादन योग्य रूप में विशिष्ट हैं।

32

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

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

एक परीक्षण लिखें
इसे विफल देखें (साबित करें कि आपको कुछ करना है)
टेस्ट पास करने के लिए सिर्फ वही लिखें जो जरूरी है - अब और नहीं।
देखो इसे पास (या!)
रिफैक्टर (इसे बेहतर बनाएं)
धोएं, कुल्ला और दोहराएं

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

अब, क्या आपको C # प्रॉपर्टीज जैसी चीजों का परीक्षण करने की आवश्यकता है? इस तरह परिभाषित एक संपत्ति की कल्पना करें:

bool IsWorthTesting {get; set;}

इसका उत्तर "नहीं" होगा यह परीक्षण के लायक नहीं है, क्योंकि इस बिंदु पर आप भाषा सुविधा का परीक्षण कर रहे हैं। बस भरोसा है कि सी # मंच के लोगों को यह सही है। इसके अलावा, अगर यह विफल हो गया, तो आप इसे ठीक करने के लिए क्या कर सकते हैं?

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

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

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

— बेरिन लोरिट्श
स्रोत

24

आपको बग की लागत के साथ परीक्षण की लागत को संतुलित करना होगा।

किसी फ़ाइल को खोलने वाले फ़ंक्शन के लिए 10 लाइन यूनिट टेस्ट लिखना, जहां विफलता "फ़ाइल नहीं मिली है" व्यर्थ है।

एक फ़ंक्शन जो एक जटिल डेटा संरचना में कुछ जटिल करता है - फिर स्पष्ट रूप से हाँ।

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

— मार्टिन बेकेट
स्रोत

23

परीक्षण जुआ है।

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

किसी भी दांव की तरह, कभी-कभी आप जीतते हैं, कभी-कभी आप हार जाते हैं।

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

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

— hotpaw2
स्रोत

3

अच्छा उत्तर। कुछ में से एक जो वास्तव में मेरे मूल प्रश्न का उत्तर देता है। मैंने इस पोस्ट को लिखने के बाद से खुद को परीक्षण की दुनिया में डूबा हुआ है (मुझे यह पसंद है। btw।) मुझे इसे और अधिक समझने की आवश्यकता है इससे पहले कि मैं वास्तव में जान सकता हूं कि इसका उपयोग कब करना है (या नहीं)। यहां बताए गए कई कारणों से मैं हर समय इसका उपयोग करना पसंद करूंगा। लेकिन यह अंततः इस पर निर्भर करेगा कि मैं इसे कितनी तेजी से प्राप्त करता हूं, क्योंकि अंत में यह मेरे समय का एक जुआ है, जो मेरी कंपनी / क्लाइंट के नियंत्रण में है, और अक्सर वे प्रोजेक्ट त्रिकोण के निचले कोनों पर ध्यान केंद्रित करते हैं: en। wikipedia.org/wiki/Project_triangle

— केन पेसिसा

10

मेरी सलाह केवल उस कोड का परीक्षण करना है जिसे आप ठीक से काम करना चाहते हैं।

उस कोड का परीक्षण न करें जिसे आप छोटी गाड़ी होना चाहते हैं और सड़क के नीचे आपके लिए समस्याएं पैदा कर सकते हैं।

— निक होजेस
स्रोत

9

मुझे यह कहते हुए याद दिलाता है कि मेरे डेंटिस्ट के पास है: आपको अपने सभी दांतों को फ्लॉस करने की ज़रूरत नहीं है, बस आप जिसे रखना चाहते हैं।

— केन प्रीस्पिसा

मैं कबूल करता हूं कि इससे मुझे क्या लगा। ;-)

— निक हॉजेस

8

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

टीडीडी और यूनिट टेस्टिंग एक ही चीज नहीं हैं।

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

टीडीडी रेड लाइट के एक लूप में कोडिंग का अभ्यास है। हरी बत्ती। रिफ्लेक्टर पुनरावृत्तियों।

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

टीडीडी के फायदे में से एक यह है कि यह सामान्य ज्ञान के बारे में सोचने की आवश्यकता को कम करता है। ऑफ-बाय-वन एरर जैसी चीजें गायब हो जाती हैं। आपको यह पता लगाने के लिए एपीआई प्रलेखन के माध्यम से शिकार करने की ज़रूरत नहीं है कि क्या यह सूची 0 या 1 से शुरू होती है, बस करें।

— पॉल कसाई
स्रोत

क्या आप इस बात पर विस्तार से बता सकते हैं कि कैसे एक-एक करके त्रुटियां गायब हो जाती हैं? क्या आप कह रहे हैं कि आप किसी दस्तावेज़ के परीक्षण की तुलना में परीक्षण के माध्यम से किसी सरणी का सूचकांक शून्य-आधारित या एक-आधारित होने के बारे में अधिक तेज़ी से अपना उत्तर प्राप्त कर सकते हैं? मेरी संभावना नहीं है - मैं Google पर बहुत तेज हूं :)

— केन प्रीस्पा

1

वास्तव में, TDD का एक एपीआई का पता लगाने के लिए एक उत्कृष्ट तरीका है (कार्यक्षमता के दस्तावेजीकरण के लिए एक विरासत कोडबेस सहित)।

— फ्रैंक शीयर

यह बहुत उपयोगी है अगर वह एपीआई कभी बदलता है ... आपके पास अचानक कुछ असफल परीक्षण हैं :-)

— बिट्सफ्लॉजिक

@ केन पेसिसा, यह निश्चित रूप से तेज है - कोड के आधार पर लिखें कि क्या आपको लगता है कि यह 0 या 1 है, इसे चलाएं, यदि आवश्यक हो तो इसे ठीक करें। अधिकांश समय, आप सही होंगे और आपने इसे देखने के लिए छोड़ दिया होगा, यदि आप गलत हैं, तो आप 10 सेकंड के भीतर जानते हैं।

— पॉल बुचर

बहुत दिलचस्प लाभ। मुझे वह पसंद है।

— केन पेसिसा 23

3

मैंने एक ऐसी प्रणाली पर काम किया जहां हमने लगभग हर चीज का परीक्षण किया। परीक्षण के लिए उल्लेखनीय निष्पादन पीडीएफ और XLS आउटपुट कोड थे।

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

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

— नमक
स्रोत

दरअसल, इस तरह का परीक्षण संभवतः "एकीकरण परीक्षण" है। और हाँ, एकीकरण परीक्षण इकाई परीक्षण की तुलना में बहुत कठिन है, और एक कारण यह है कि कभी-कभी "सही" के नियम बहुत जटिल होते हैं, या व्यक्तिपरक भी होते हैं।

— साल्स्के

2

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

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

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

टीएल, डॉ। यह वास्तव में कभी भी उचित नहीं है क्योंकि लाभ बहुत अच्छे हैं।

— स्टीवन एवर्स
स्रोत

2

दो बहुत अच्छे जवाब मैं यहाँ आया हूँ:

कथित उपरि से बचने का औचित्य:

अपनी कंपनी के लिए तत्काल समय / लागत की बचत
आपके चले जाने के बाद भी लंबे समय में समस्या निवारण / स्थिरता / विस्तार में संभावित समय / लागत की बचत।

क्या आप अपने काम की गुणवत्ता के प्रमाण के रूप में अपनी ओर से एक महान उत्पाद नहीं छोड़ना चाहेंगे? स्वार्थी शब्दों में बोलते हुए, क्या यह आपके लिए बेहतर नहीं है कि आप क्या करते हैं?

— आदित्य पी
स्रोत

1

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

— केन पेसिसा

1

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

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

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

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

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

— स्टीव
स्रोत

मुझे प्रतिगमन को रोकने और आत्मविश्वास को जोड़ने के विचार पसंद हैं। वे बिल्कुल कारण हैं जो मैं परीक्षण जोड़ना चाहूंगा।

— केन प्रीस्पिसा

1

ऐसा लगता है कि अधिकांश उत्तर प्रो-टीडीडी हैं, भले ही सवाल टीडीडी के बारे में नहीं पूछ रहा था, लेकिन सामान्य रूप से यूनिट परीक्षणों के बारे में।

यूनिट टेस्ट क्या है या यूनिट टेस्ट नहीं है इसके पीछे पूरी तरह से वस्तुनिष्ठ नियम नहीं है। लेकिन कई बार ऐसा लगता है कि कई प्रोग्रामर यूनिट टेस्ट नहीं करते हैं:

निजी तरीके

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

आपके द्वारा पहले से ही जानी जाने वाली चीजें (या किसी और द्वारा परीक्षण की गई चीजें)

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

वे दोनों आवेदन कर सकते हैं कि आप टीडीडी कर रहे हैं या नहीं।

— Ravenstine
स्रोत

0

केन, मैं और कई अन्य डेवलपर वहां उसी निष्कर्ष पर पहुंचे हैं, जब आप हमारे करियर के दौरान कई बार आए थे।

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

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

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

उसके बाद एकमात्र मुश्किल हिस्सा यह पता लगाना है कि आप जो भी प्रोजेक्ट कर रहे हैं उसके लिए सबसे अच्छा "हिरन के लिए बैंग" है।

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

सौभाग्य!

— एडम कार्स्टेंसन
स्रोत

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

— केन प्रीस्पा

मुझे लगता है कि आप सबस्पेक (यह बीडीडी से प्रेरित है) जैसे फ्रेमवर्क का उपयोग करने से लाभान्वित हो सकते हैं, जिससे आपको संदर्भ सेटअप साझा करते समय अलगाव ("सबटेस्ट") अलगाव प्राप्त करने की अनुमति मिलेगी।

— जोहान्स रूडोल्फ