इकाई परीक्षण के लिए मेरे लिए मेरी परियोजना कितनी बड़ी होनी चाहिए? [बन्द है]

86

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

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

— लमिन सनेह
स्रोत

26

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

— एमोस कारपेंटर

6

इसके बारे में कैसे (C # .NET के लिए): int x = 3 * (1/3); ऑपरेशन पूरा होने के बाद x में संग्रहीत मूल्य क्या है? मेरी बात यहां तक कि एक लाइन कोड के परीक्षण की आवश्यकता हो सकती है क्योंकि यह बग का कारण बन सकता है, या तो क्योंकि आप नहीं जानते हैं या क्योंकि आप जानते हैं लेकिन गलत कोड किया था।

— NoChance

2

@ आमोस, मुझे लगता है कि आपको मेरी बात याद आ रही है। यह तथ्य कि मुझे यह प्रश्न अकेले पूछा गया है, यह दर्शाता है कि मैं कोड रीडर के लिए भी खानपान पर विचार करता हूं।

— लामिन सनेह

13

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

— साने

1

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

— मार्क ई। हासे

206

आपका प्रोजेक्ट पहले ही काफी बड़ा है।

मेरे अनुभव में, एक वर्ग और एक फ़ंक्शन इकाई परीक्षण की आवश्यकता पर विचार करने के लिए पर्याप्त है।

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

— कुटकी
स्रोत

24

निश्चित रूप से आपको पहले शुरू करना चाहिए, 0 क्लास / 0 फंक्शन पॉइंट पर ... अगर आप टीडीडी :) का पालन कर रहे हैं :)

— कज़ ड्रैगन

115

+1। यदि आप प्रोग्राम बग्स के लिए काफी बड़े हैं, तो यूनिट टेस्ट करवाना काफी बड़ा है।

— जेसन ओरेंडोर्फ

9

@JasonOrendorff: मैं इसे पोस्टर में लिखकर अपने कार्यालय में रख रहा हूं। प्रतिभाशाली।

— जस्टिन ᚅᚔᚈᚄᚒᚔ

इसके अतिरिक्त यह "सुरक्षित" रीफैक्टरिंग के लिए अनुमति देता है।

— तिमो

7

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

— चू 0

109

मैंने कभी भी "आप सभी को परीक्षण करना चाहिए" विचार में यूनिट नहीं खरीदा है, हालांकि निश्चित रूप से वहाँ के लोग हैं, जिनके पास ( gnat का जवाब देखें !)।

जहां तक मेरा सवाल है, यूनिट टेस्टिंग के मुख्य लाभ हैं:

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

मूल रूप से आपको इन कारकों के खिलाफ परीक्षण लिखने और बनाए रखने में लगने वाले समय को तौलना होगा।

नंबर 1 आमतौर पर इसे लिखने के परीक्षण के लायक बनाने के लिए पर्याप्त है। मेरे अनुभव में,> 95% कोड जल्दी या बाद में संशोधित हो जाता है।

— vaughandroid
स्रोत

8

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

— मैट विल्को

1

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

— वेन वर्नर

10

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

— डैन नीली

3

उह, मुझे लगता है कि आपने एक को याद किया: "यह सुनिश्चित करने के लिए कि कोड उस तरीके से काम करता है जो इसे माना जाता है!"

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

3

@ BlueRaja-DannyPflughoeft: वास्तव में, यह कहना अधिक सटीक होगा: "सुनिश्चित करें कि कोड आपके द्वारा लिखे गए यूनिट परीक्षणों को पास करता है!"

— 15 फरवरी को vaughandroid

34

यह सरल है: आपको इकाई परीक्षण की आवश्यकता नहीं है यदि आप इसे एक बार चलाने के बाद कार्यक्रम को छोड़ देंगे।

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

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

— किलियन फोथ
स्रोत

22

प्रोग्रामर भविष्य की भविष्यवाणी करने के अपने स्वयं के कौशल को पहचानने में कुख्यात हैं

— सुपरएम

3

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

— जल

@ यालयन का बस इतना ही जवाब नहीं है कि इस अहसास के जल्द से जल्द वापस आने और यूनिट परीक्षणों को जोड़ना चाहिए?

— कॉर्नेल मैसन

@CornelMasson आप बिल्कुल सही हैं, उम्मीद करते हैं कि प्रबंधकों को यह समझाना अक्सर मुश्किल होता है कि "यह अभी तक समाप्त नहीं हुआ है" क्योंकि परीक्षण गायब हैं :-)

— जलयेन

@ जयलीन: बहुत सच!

— कॉर्नेल मासन

22

कुछ समय पहले मुझे एक अच्छी पोस्ट मिली: यूनिट टेस्टिंग ने विकास को गति क्यों दी । यह प्रश्न का उत्तर देने में आपकी सहायता कर सकता है।

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

मुझे भरोसा है"।

यह शायद सबसे महत्वपूर्ण कारण है कि इकाई परीक्षण उद्यम के संदर्भ में विकास को गति देते हैं।

मुझे भरोसा है कि सब कुछ अभी भी काम करता है अगर सभी परीक्षण पास होते हैं। यदि परीक्षण विफल हो जाते हैं, तो वे ठीक उसी जगह इंगित करेंगे जहां समस्या देता है ...

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

माइकल फेदर्स ने अपनी पुस्तकों में से एक में कोड में बदलाव के साथ काम करने के दो तरीके पेश किए:

संपादित करें और प्रार्थना करें,
कवर और संशोधित करें।

इससे कोई फर्क नहीं पड़ता कि कोड आधार कितना बड़ा है।

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

18

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

अगर मैं आम तौर पर एक तरह की गलती नहीं करता (जैसे एक कंस्ट्रक्टर में गलत चर सेट करना), तो मैं इसके लिए परीक्षण नहीं करता।

— Mansuro
स्रोत

4

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

— नाथन लॉन्ग

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

— xaxxon

@xaxxon: केंट वास्तव में उसी उत्तर के बारे में बात करता है जिसमें मानसरो से जुड़ा हुआ है, कह रहा है: "जब एक टीम पर कोडिंग होती है, तो मैं अपनी रणनीति को सावधानीपूर्वक परीक्षण कोड में संशोधित करता हूं कि हम, सामूहिक रूप से, गलत हो जाते हैं।"

— henko

नहीं, यह अभी भी अविश्वसनीय रूप से कम देखा गया है। आप नहीं जान सकते कि भविष्य में कौन कोड पर काम करेगा। यह उस प्रकार की मानसिकता है जो जूनियर डेवलपर्स को प्रभावित करती है।

— xaxxon

5

समय बचाने और सुधार के लिए यूनिट परीक्षण लागू किए गए हैं:

बस पर नज़र रखना
कोड को फिर से लिखना और / या फिर से लिखना
एकीकरण जांच
प्रतिगमन परीक्षण, आदि।

कार्यक्रम के अपेक्षाकृत जटिल भागों के लिए इकाई परीक्षण लिखना आवश्यक है।

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

— Superm
स्रोत

आम तौर पर एक अच्छा जवाब है, इसलिए +1। हालाँकि, मुझे लगता है कि आपका अंतिम बिंदु इस तथ्य को याद करता है कि आप अभी भी अपने यूनिट परीक्षणों का मैन्युअल परीक्षण करना चाहते हैं / चाहते हैं!

— विघ्नहर्ता

@ बक्वेटा, शायद मुझे स्पष्ट नहीं लग रहा था, लेकिन मेरा मतलब यह नहीं था कि इकाई परीक्षण पूरी तरह से मैनुअल परीक्षण की जगह लेते हैं

— सुपरएम

4

"क्या मुझे इसका परीक्षण करना चाहिए" आमतौर पर निम्नलिखित प्रश्न का उत्तर देकर कहा जा सकता है: "क्या यह महत्वपूर्ण है कि यह फ़ंक्शन ठीक से काम करता है, और क्या मेरे लिए यह जानना महत्वपूर्ण है कि यह कब काम करना बंद कर देता है?"

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

— ब्रायन ओकली
स्रोत

4

जब तक आप इसे परीक्षण के बिना कोड लिखने जा रहे हैं, आप हमेशा परीक्षण की लागत को उठाना चाहते हैं।

यूनिट परीक्षणों के होने और उनके न होने के बीच का अंतर परीक्षण लिखने की लागत और हाथ से परीक्षण की लागत की तुलना में इसे चलाने की लागत के बीच का अंतर है।

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

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

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

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

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

TL; DR संस्करण:

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

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

— मार्क बूथ
स्रोत

3

जैसे ही आप निरीक्षण करते हैं कि प्रतिगमन होता है या डर आपके संपादन के साथ कुछ कारण बनता है और ध्यान नहीं दे रहा है।

उस डर को दूर करें, इसे पर्याप्त आकार तक बढ़ने दें: जितनी जल्दी आप परीक्षण करेंगे, उतना ही बेहतर होगा।

कृपया ध्यान दें: परियोजना में आपकी भूमिका के आधार पर, यूनिट परीक्षण केवल उस प्रकार के परीक्षण नहीं हो सकते हैं, जिस प्रकार आप लिखना चाहते हैं।

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

— ZJR
स्रोत

1

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

— लामिन सनेह

1

कम से कम दो अन्य प्रकार के परीक्षण हैं - एकीकरण परीक्षण, और स्वीकृति परीक्षण। इकाई परीक्षण एक विशिष्ट इकाई को कवर करते हैं (जैसे कि इस वर्ग का यह कार्य Frab to Fizz माना जाता है)। आप अन्य सभी स्थानों पर उस स्थान पर मॉक / स्टब करते हैं जहां वह वर्ग इंटर करता है, इसे el fake-o data से गुजारें। जब आप एकीकरण परीक्षण करते हैं, तो आप यह सुनिश्चित करने के लिए दो (या अधिक) कक्षाओं को जोड़ते हैं कि आपकी कक्षाएं जिस तरह से आप सोचते हैं कि उन्हें एक साथ जाना चाहिए। आखिरकार आप पर्याप्त परीक्षण बनाते हैं जो आप अपने पूरे सिस्टम की एंड-टू-एंड टेस्टिंग कर रहे हैं, जिसे कभी-कभी "स्मोक टेस्ट" के रूप में जाना जाता है।

— वेन वर्नर

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

— जेडजेआर

1

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

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

रॉबर्ट सी। मार्टिन के "क्लीन कोड" का एक उद्धरण : "यदि यह लिखने के लिए तुच्छ है, तो यह परीक्षण करने के लिए तुच्छ है", इसलिए लघु और तुच्छ कार्यक्रमों के लिए परीक्षण पर छोड़ देने का कोई बहाना नहीं है।

— ईविंद ईडीम एल्सथ
स्रोत

0

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

— जॉन डाहले
स्रोत

-1

किसी प्रोजेक्ट को कक्षाओं या कार्यक्षमता की सीमा में बांधना और फिर यह देखना कि यह यूनिट परीक्षण के लिए उपयुक्त है या गलत है। यूनिट के परीक्षण के कई लाभ हैं लेकिन असली सुंदरता तब शुरू होती है जब आपको किसी एप्लिकेशन को बनाए रखना पड़ता है या वितरित वातावरण में काम करना पड़ता है। तो पसंद यहाँ आता है। यहां तक कि आपके कोड में एक छोटा सा भी बदलाव आपदाओं का कारण बन सकता है।
मैं न केवल 'यूनिट टेस्टिंग' का सुझाव दूंगा बल्कि आपके कोड कवरेज को जांचने की भी सिफारिश करूंगा, यह सुनिश्चित करना कि आपका अधिकतम कोड यूनिट टेस्ट से कवर हो। कोड कवरेज के लिए सीमा 95% से कम नहीं होगी और लक्ष्य लगभग 100% होना चाहिए । आप अपने कोड कवरेज को ट्रैक करने और एक रिपोर्ट उत्पन्न करने के लिए टूल के लिए जा सकते हैं।
विजुअल स्टूडियो कवरेज डेटा प्रदान करता है -http://msdn.microsoft.com/en-us/library/ms182496(v=vs.80).aspx
इसके अलावा आप NCover या dotCover का उपयोग कर सकते हैं।

— Niks
स्रोत