यूनिट परीक्षण के मूल्य की व्याख्या कैसे करें


30

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

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

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

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


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

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

महान द आर्ट ऑफ़ यूनिट टेस्टिंग में इस पर एक पूरा अध्याय है ।
स्टुपेरयूज़र

6
@Wayne, Everytime मैंने आपके एक प्रश्न को पढ़ा, मुझे विश्वास है कि आपको एक नई नौकरी खोजने की आवश्यकता है। वे सॉफ्टवेयर विकास में एक पुराना पुराना अवशेष हैं और आप नहीं हैं। यदि आपके लिए एक विंडो खुलती है तो आप उसके लिए कूदते हैं और पीछे मुड़कर नहीं देखते।
maple_shaft

2
@WayneM, छोड़ो। गंभीरता से।
AK_

जवाबों:


18

मैं अपने सहकर्मियों को इकाई परीक्षणों (और सामान्य रूप से परीक्षण) की अवधारणा को पेश करना चाहता हूं

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

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

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

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

यह संबंधित धागा भी देखें: स्वचालित इकाई परीक्षण, एकीकरण परीक्षण या स्वीकृति परीक्षण

और SO से पहले वाला: इकाई परीक्षण क्या है?


4
व्यावहारिक पहलू के लिए +1। हमने अपने 50+ देव में ऐसा किया। दुकान और यह पर पकड़ रहा है। हर बार हमें एक और देव मिलता है। परीक्षण लिखना, वे झुके हुए हैं।
एले

खराब हिस्सा यह है कि वह परीक्षण लिख रहा है, लेकिन उसके सहकर्मियों को उनके बारे में पता नहीं है और उत्पादन कोड में कुछ बदल जाएगा, जिससे परीक्षण विफल हो जाएगा जिससे उसके सभी प्रयास रद्द हो जाएंगे :(
इगोर पोपोव

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

12

रि-फैक्टर विदाउट फियर

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

  • "मैं इस कोड को नहीं छूना चाहता क्योंकि मुझे डर है कि मैं इसे तोड़ दूंगा"
  • "मैं इस कोड को pof करने के लिए नई कार्यक्षमता लिखना नहीं चाहता क्योंकि मुझे नहीं पता कि यह कैसे काम करता है"
  • "गुप्त रूप से, मुझे उस कोड से डर लगता है"

मैं और अधिक वीणा कर सकता था, लेकिन यह अच्छी तरह से कवर किया गया है जैसे टीडीडी पर अंकल बॉब और टीडीडी पर मार्टिन फाउलर

निर्भरता

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

बॉब: "ओह c% ^ p! बॉस बस हम सभी को MS SQL Server 2008 का उपयोग करने के लिए मजबूर करते हैं" जेन: "यह ठीक है, कम से कम नुकसान हुआ है क्योंकि हम हमारे डेटासोर्स और हमारे डीएओ कक्षाओं को प्रभावित करते हैं, मुझे बहुत खुशी है कि टीडीडी ने प्रोत्साहित किया हमें उस रास्ते से नीचे उतारो। "


4

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

जब हमारे पास अच्छे स्वचालित परीक्षण मामले होंगे, तो परिणाम जल्दी, आत्मविश्वास और भय रहित विकास होंगे (यह बग फिक्सिंग, वृद्धि या पुन: फैक्टरिंग हो सकता है)।


4

आकलन करो

  • t mt = उस समय को मैन्युअल रूप से परीक्षण करने के लिए आवश्यक है जो आप पर प्रभाव डालते हैं
  • t wt = परीक्षण लिखने के लिए आवश्यक समय
  • k = नया कोड जारी करने से पहले आपको जितनी बार संभवत: हर चीज का परीक्षण करना होगा

    अगर (t wt <t mt ) या (t wt <(k * t mt )) तो यह नो-ब्रेनर है: टेस्ट लिखने से विकास को गति मिलेगी।

अन्यथा अनुपात देखें (t wt / / (k * t mt ))। यदि यह एक बहुत बड़ी संख्या है, तो एक और अवसर की प्रतीक्षा करें; अन्यथा प्रतिगमन-परीक्षण लाभों के साथ उचित है।

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

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


मैं आपको +1 दे रहा हूं, लेकिन वह गणित डरावना लग रहा है!
वेन मोलिना

@ यह केवल सदस्यता है, वे भयभीत कर रहे हैं । लेकिन प्रोग्रामिंग बहनों के लिए नहीं है! ;-)
स्टीवन ए। लोव

1

यदि आप एक Microsoft दुकान हैं, तो एक सुझाव: MSDN पर कुछ डॉक्यूमेंटेशन ढूंढें, जो यूनिट टेस्टिंग या ढीली कूपिंग को एक सर्वोत्तम अभ्यास के रूप में सुझाता है (मुझे यकीन है कि इस के कई उदाहरण हैं ) और इस पर इशारा करते हैं अगर कोई टकराव होता है।

यह काम करने के एक तरीके की तरह लग सकता है, लेकिन मैंने पाया है कि 'सर्वोत्तम अभ्यास' शब्द का उपयोग करने से आपको प्रबंधन के लिए विशेष रूप से एक लंबा रास्ता तय करना होगा।


1

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

यहाँ खोजशब्द विकास है, क्रांति नहीं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.