एक टीम में नए आदमी होने के दौरान आप मौजूदा एकीकरण और इकाई परीक्षणों की गुणवत्ता के बारे में क्या कर सकते हैं?


21

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

साक्षात्कार के दौरान आपको प्रबंधन द्वारा बताया जाता है कि वे "दृढ़ता से इकाई परीक्षण का समर्थन करते हैं" और वे खुले तौर पर इसे प्रोत्साहित करते हैं। वे करते हैं, लेकिन परीक्षणों के बारे में सब कुछ खुद स्पष्ट है। इस तथ्य की तरह कि वे 100% एकीकरण परीक्षण कवरेज का दावा कर रहे हैं लेकिन 100% एकीकरण इकाई परीक्षण कवरेज से कम है। कुछ अन्य समस्याएं जो मुझे मिली हैं:

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

  2. एकीकरण परीक्षण जिसमें एक विशिष्ट वातावरण के डेटाबेस पर बहुत विशिष्ट गतिशील डेटा पर स्पष्ट निर्भरताएं हैं।

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

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

  5. कोई स्पष्ट नामकरण परंपराएं जल्दी से एक परीक्षण के नाम को देखने और मोटे तौर पर यह निर्धारित करने के लिए कि क्या परीक्षण किए जा रहे हैं।

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

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

जब आप खुद को इस स्थिति में पाते हैं तो आप क्या करते हैं? आपको क्या लगता है कि हमले की सबसे अच्छी योजना कुछ इस तरह से निपटना होगी?

क्या सभी परीक्षणों को एक स्मारकीय प्रयास में रिफैक्ट किया जाना चाहिए? क्या आपको सिर्फ इस विचार को छोड़ देना चाहिए कि इस विरासत परियोजना में एक दिन की ठोस इकाई परीक्षण कवरेज हो सकती है?


6
वास्तविक दुनिया में आपका स्वागत है, दोस्त।
tdammers

20
खुश रहो तुम परीक्षण किया है।
जोएल एथर्टन

3
आप उन कंपनियों के लिए क्यों काम करते हैं जो स्पष्ट रूप से आपकी योग्यता के स्तर से नीचे हैं?
ट्रोजननाम 14

3
@ ब्रायन, मैं अहंकार स्ट्रोक की सराहना करता हूं, लेकिन मेरे जैसे लोगों के बारे में अधिक सोच के बिना, फिर ये कंपनियां कभी भी ऊपर नहीं उठेंगी। यह पहली बार है जब मैं सत्ता की वास्तविक स्थिति में हूं, क्योंकि मैंने एक बार के लिए राजनीतिक महत्व की एक मामूली राशि विकसित की है। चीजों को बेहतर बनाने के लिए संसाधनों को निर्देशित करने के लिए मेरे पास यहां एक वास्तविक अवसर है। मुझे अभी तक कोई ऐसी कंपनी नहीं मिली है जो काम की आवश्यकता के बिना परिपूर्ण हो। यह पूर्ण पति या पत्नी की तरह है, वे सिर्फ साथ नहीं आते हैं, एक अच्छा पर्याप्त व्यक्ति साथ आता है और फिर आप उन्हें बदल देते हैं कि आप उन्हें क्या चाहते हैं;)
मेपल_शफ्ट

1
मुझे लगता है कि हम उसी टीम के लिए काम कर सकते हैं। अब आप (और मैं) जानते हैं कि वास्तव में हमारे अगले साक्षात्कार के दौरान सवाल पूछने के बारे में कैसे जाना जाता है। (वास्तव में, मेरा वातावरण 100% या यहां तक ​​कि 10% एकीकरण परीक्षण कवरेज के पास है [असली इकाई परीक्षण? यह पागल बात है!], लेकिन आपने उन सभी अन्य बिंदुओं पर ध्यान दिया है जिनसे मैं निपट रहा हूं।)
एंथनी पेग्राम

जवाबों:


6

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

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

एक बेहतर विचार यह होगा कि उनसे बात करने की कोशिश करें ताकि वे प्रयास में भाग ले सकें, और आपके पास स्मार्ट-गधे के रूप में प्रकट होने की संभावना कम होगी, यह "मैं" की तुलना में अधिक "हम" होगा।

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

  1. इकाई और एकीकरण परीक्षणों के बीच अंतर कैसे करें? निम्नलिखित समाधान लागू हो सकते हैं और अनन्य नहीं हैं:

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

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

आप ध्यान दें कि चरण 1, 2 और 3 एकल परीक्षण वर्ग पर किया जा सकता है, यदि आप जल्दी से सहयोगियों / प्रबंधन को दिखाना चाहते हैं कि यह कैसे किया जा सकता है। यह भी उपयोगी होगा, जैसा कि Péter Török ने लिखा है, ताकि तुरंत अपने साथियों को "अच्छा रास्ता" दिखा सकें ताकि वे खराब कोड का उत्पादन करना बंद कर दें। हालाँकि मुझे लगता है कि बाकी 2 चरण, पूरे परीक्षण डेटासेट की पहचान करते हुए, एक बड़े कदम में सबसे अच्छा किया जाता है।

उस सब के पीछे एपीआई / प्रौद्योगिकी के रूप में, आप इस विषय को जानते हैं।

उम्मीद है कि थोड़ा मदद की।

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


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

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

14

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

जब तक आपके पास गुणवत्ता परीक्षण कवरेज नहीं है, सबसे पहले, आप मौजूदा कोड को 'ठीक' नहीं कर सकते या रिफ्लेक्टर नहीं कर सकते हैं, इसलिए मैं पहले आपके परीक्षण के बुनियादी ढांचे को ठीक करने पर ध्यान केंद्रित करूंगा।

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

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

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

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


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

2
लड़के स्काउट नियम के लिए +1 , किसी भी ओवरहाल दृष्टिकोण की तुलना में उपयोग करना और बेचना बहुत आसान है।
मैथ्यू एम।

10

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

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

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

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


6

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

धैर्य और सम्मान के साथ, उन सर्वश्रेष्ठ लोगों के रूप में, जिनके साथ आप काम कर रहे हैं, गड़बड़ होने के बावजूद। वे सभी संभावना में, सही काम करने की कोशिश कर रहे हैं; इसे ध्यान में रखें और उन्हें ऐसा करने में मदद करें।


2
मुझे यह उल्लेख करना चाहिए कि अब कोई भी मूल गड़बड़ निर्माता यहाँ नहीं हैं। वे ऐसा महसूस नहीं करते थे कि उनके द्वारा बनाए गए तकनीकी ऋण से निपटना और आगे बढ़ना।
maple_shaft

4
@maple_shaft: यह अच्छा है कि वे चले गए हैं ... आप बिना किसी को खोए चीजों को सुधार सकते हैं।
केविन क्लाइन 15

2

टीम में नया होने के बारे में अच्छी बात यह है कि आपके पास चीजों के लिए "ताज़ा" दृष्टिकोण है। बुरा हिस्सा यह हो सकता है कि दूसरों को आप पर विश्वास करने में मुश्किल हो सकती है।

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

लेकिन इसे धीमा करें, एक-एक करके, और उम्मीद करें कि आपके विचार धीरे-धीरे नए समूह के बीच "पकड़" रहे हैं।


2

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

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

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

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

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


2

उन्हें समय पर ठीक करें

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

मैं व्यक्तिगत रूप से परवाह नहीं करता अगर एक परीक्षण एक इकाई परीक्षण या एकीकरण परीक्षण है जब तक कि यह एक अच्छा परीक्षण है। अच्छे परीक्षण से मेरा मतलब है कि यह:

  • अपने आप साफ हो जाता है
  • दोहराने योग्य है
  • पर्यावरणीय बातचीत को कम करता है
  • संगत है

जिस तरह से मैंने बेहतर परीक्षण निर्माण का प्रचार किया (जो कि मुझे लोगों को बहुत बुरा कहना है)।

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