यूनिट टेस्टिंग नौसिखिया टीम को यूनिट टेस्ट की जरूरत है


37

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

क्या कोई ऐसी ही स्थिति में है? टीडीडी के साथ सहज होने के लिए एक टीम प्राप्त करने का एक प्रभावी तरीका क्या है जब उन्होंने कोई इकाई परीक्षण नहीं किया है? क्या यह कुछ चरणों में ऐसा करने के लिए समझ में आता है? या क्या हमें एक ही बार में सभी बढ़ते दर्द का सामना करना चाहिए?

संपादित करें

स्पष्टीकरण के लिए, टीम (स्वयं के अलावा) पर कोई भी नहीं है जिसके पास कोई इकाई परीक्षण जोखिम / अनुभव है। और हम Visual Studio में निर्मित इकाई परीक्षण कार्यक्षमता का उपयोग करने की योजना बना रहे हैं।


+1 यह सवाल लगभग उसी स्थिति की रूपरेखा तैयार करता है, जिसमें मैं वी.एस. के बजाय केवल एक्लिप्स पीएचपी देव के लिए हूं।
canadiancreed

इस मंच के लिए उपयुक्त प्रश्न नहीं है
रयान

2
आपने आखिर में क्या किया? वास्तव में सुनना चाहेंगे कि यह कैसे निकला।
स्नूप

जवाबों:


36

मौजूदा कीड़े / दोषों पर अभ्यास करें।

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

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

  1. एक अपेक्षित पूर्व शर्त और पोस्टकंडिशन
  2. एक परिणाम जो वर्तमान में वह नहीं है जो अपेक्षित है और उस पूर्व शर्त / पोस्टकंडिशन का उल्लंघन करता है

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

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


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

बग के लिए परीक्षण लिखें, यह अच्छी सलाह है।
अमिताभ

32

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

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

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

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

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

  5. जब टीम सहज होने लगे, तो सभी नई कार्यक्षमता को TDD तरीके से लिखा जाए। यह आपकी परियोजना के आकार पर निर्भर करता है, लेकिन कुछ समय बाद आपको एक अच्छी अच्छी कवरेज मिलनी चाहिए, जिसमें पुराने तरीके से लिखे गए आपके प्रोजेक्ट के केवल कुछ विरासत हिस्से शामिल हैं।

  6. इस बिंदु से, टीम को पहले से ही टीडीडी को समझना और गले लगाना चाहिए, और विरासत (गैर टीडीडी) सामान को काम करने के लिए मुश्किल और कष्टप्रद माना जाना चाहिए। इसे पुनः प्राप्त करें: अधिकांश पोप इसे खुशी के साथ करेंगे।

कुछ अन्य महत्वपूर्ण बिंदु:

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

  • सुनिश्चित करें कि परीक्षणों को चलाना आसान है और समाप्त होने में ज्यादा समय नहीं लेना (या धोखा देना, उदाहरण के लिए परीक्षणों के लिए इन-मेमोरी डीबी का उपयोग करके)।

  • कुछ निरंतर एकीकरण सॉफ्टवेयर सेट करें, ताकि टूटे हुए परीक्षण तुरंत मिल जाएं।


1
संभवतः सबसे महत्वपूर्ण है ऑन-बोर्ड प्रबंधन प्राप्त करना।
टॉड

18

टीडीडी के साथ सहज होने का एक तरीका यह है कि पहले एकीकरण परीक्षण लिखें। बाद में परीक्षण सीम और सच्ची इकाई परीक्षणों का परिचय दें।

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

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


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

1
आप दूसरे पैरा पर हाजिर हैं। कोड का परीक्षण करना कठिन है, लेकिन क्योंकि बिना किसी परीक्षण के एक विरासत कोड-बेस पर इसका रिफ्लेक्टर कोई विकल्प नहीं है। परीक्षण तो लागू करने के लिए इतना मुश्किल हो सकता है कि यह लोगों को परेशान करने के लिए बंद कर देता है।
टॉड

3

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

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


3

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


2

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


0

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

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

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

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