क्या कोड समीक्षा के दौरान परीक्षण लिखना फायदेमंद नहीं होगा?


24

मेरे एक सहकर्मी को एक विचार आया, जो मुझे दिलचस्प लगा।

क्या कोड समीक्षा के दौरान परीक्षण लिखना फायदेमंद नहीं होगा, समीक्षा करने वाले व्यक्ति द्वारा यह मानकर कि हम TDD नहीं करते हैं?

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

पेशेवरों मुझे मिला:

  1. सार्थक परीक्षणों को लिखने के लिए समीक्षा के दौरान कोड की गहरी समझ को प्रोत्साहित करता है।
  2. फिर आप उन परीक्षणों की कोड समीक्षा जोड़ सकते हैं जो कोड के लेखक द्वारा परीक्षण किए जा रहे हैं।

विपक्ष मैंने पाया:

  1. कोड लेखन और परीक्षण के बीच फीडबैक लूप बढ़ता है।

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


3
आपने उल्लेख नहीं किया है कि परीक्षण का यह बेड़ा परीक्षण के ऊपर और ऊपर होगा जो विकास के दौरान या उसके स्थान पर होना चाहिए।
रोबी डे

3
यह लाभदायक होगा, लेकिन अगर हम "टीडीडी नहीं करते हैं" तो एकतरफा (परीक्षण-अलग-अलग) लिखने के लिए अलग है क्योंकि गैर टीडीडी-कोड आमतौर पर अलग करना मुश्किल है। एक्सेप्टेंस टेस्ट और / या इंटीग्रेशन टेस्ट लिखना भी डिफिकल्ट और / या नाज़ुक होगा यदि आपके पास एक डेटाबेस एब्स्ट्रैक्शन लेयर (रिपॉजिटरी एपी) नहीं है जो आपको रिप्रेजेंटेबल, नॉन-नाज़ुक प्री-कंडीशन्स को परिभाषित करने की अनुमति देता है।
k3b

4
@JoulinRouge: TDD इससे मदद करता है। चूंकि कोई कोड नहीं है, आप अपने कोड के परीक्षण को दर्जी नहीं कर सकते।
जोर्ज डब्ल्यू मित्तग

6
ऐसा लगता है कि यह वास्तव में एक लंबी कोड समीक्षा होगी।
डेविड का कहना है कि मोनिका

2
मैंने उन स्थानों पर काम किया है जहां एक सहकर्मी की समीक्षा में एक साथी प्रोग्रामर शामिल है जो आपके द्वारा लिखी गई प्रत्येक पंक्ति को देख रहा है, उन्हें शैली दिशानिर्देशों और सर्वोत्तम प्रथाओं के खिलाफ जाँच कर रहा है, और उस इकाई परीक्षण को लिख रहा है जिसे आप लिखना नहीं चाहते थे।
कैंडिड_ओरेंज

जवाबों:


7

क्या कोड समीक्षा के दौरान परीक्षण लिखना फायदेमंद नहीं होगा, समीक्षा करने वाले व्यक्ति द्वारा?

मैंने पाया है कि परीक्षण लिखने का एक अच्छा समय वह है जब आपको एहसास होता है कि आपको किसी स्थिति के लिए परीक्षण की आवश्यकता है।

कंप्यूटर के लिए कार्य स्विचिंग महंगा है - मनुष्यों के लिए और भी अधिक।

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

यदि कोड की समीक्षा के दौरान ऐसा होता है, तो आगे जाकर ऐसा क्यों नहीं किया जाता है? मैंने पहले भी ऐसा किया है। मैंने पाया है कि यह बेहतर नहीं है, खासकर यदि आप इसे जल्दी से कर सकते हैं, और इससे भी बेहतर अगर आप इसे अन्यथा नहीं करेंगे।

यह मानते हुए कि हम TDD नहीं करते हैं?

भले ही आप TDD का अभ्यास करते हों, अगर आपको पता है कि कोड की समीक्षा करते समय आपको एक परीक्षा की आवश्यकता होती है, तो जो आपके पास नहीं है, वह परीक्षण तब और क्यों नहीं लिखा जाता है?

पेशेवरों

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

क्या यह वास्तव में एक नियम है कि अधिक परीक्षणों से अधिक कोड हो सकते हैं? यदि परीक्षण की आवश्यकता थी, और परीक्षण के लिए कोड की आवश्यकता थी, और अब आपके पास यह है, तो यह एक अच्छी बात है।

चेतावनियां

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


22

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

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

मेरी पुस्तक में ये सभी जीत हैं।


5
यह लगभग वैसा ही है जैसे आपको कोड की समीक्षा करने का अनुभव हो ...
syb0rg

पता नहीं क्या आप @ syb0rg के बारे में बात कर रहे हैं ... आप इसे साबित नहीं कर सकते। =;) -
रबरबैक


2
इसके अलावा, एक परीक्षण का मामला समीक्षा में खोजे गए दोष का वर्णन करने के कम से कम अस्पष्ट तरीके के बारे में है :-)
स्टीव जेसोप

1
@ syb0rg रबर डक ने हजारों या लाखों प्रोग्रामरों को अपना कोड ठीक करने में मदद की है । एक से अधिक बार देखे गए कोड की समीक्षा करने के लिए कौन बेहतर है?
jpmc26

18

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

कोड की समीक्षा के दौरान परीक्षण लिखने से पारंपरिक मैनुअल परीक्षण के रूप में एक ही समस्या का सामना करना पड़ेगा - व्यवसाय के नियमों की समझ डेवलपर से डेवलपर तक भिन्न हो सकती है जैसा कि परिश्रम।

वहाँ भी पुरानी पुरानी चर्चा है जो चलेंगे और चलेंगे कि क्या डेवलपर्स अपने कोड का इतनी अच्छी तरह से परीक्षण करेंगे अगर उन्हें पता था कि आगे और ऊपर एक परीक्षण कार्य है जो अधिक गंभीर कीड़े को पकड़ना चाहिए।


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

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

समस्या को "सुधारवादी पूर्वाग्रह" कहा जाता है।
ArTs

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

1
@ रोबीडी अगर दोष का रिसीवर वास्तव में मायने रखता है, तो आपके पास अस्वस्थ विकास का माहौल है। यह कुछ परीक्षणों को याद करने से कहीं अधिक बदतर है जो उपयोगी होगा।
jpmc26

5

मैं @ RobbieDee के उत्तर से सहमत हूं लेकिन मेरे पास जोड़ने के लिए थोड़ा अधिक है।

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

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

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

ओपी ने एक एडिट किया जहां वे एक मुश्किल या एल्गोरिथ्म हैवी फीचर के आगे के विवरण को लेआउट करते हैं।

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

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

इस तथ्य के बाद कि भीड़-प्रोग्रामिंग के बाद मुझे लगता है कि समस्या को देखने और सुधार के सुझाव देने वाली कई आंखों के समान फायदे होंगे और यदि आपकी टीम आरामदायक संचालन कर रही है तो इससे मदद मिल सकती है लेकिन मैं वास्तव में आवश्यक रखने की कोशिश करूंगा यह घटकर न्यूनतम हो जाता है क्योंकि मुझे लगता है कि यह टीम को धीमा कर सकता है।


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

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

@Encaitar मैं सहमत हूं, यह सिर्फ एक विशाल समय सिंक की तरह लगता है जो शायद चीजों को पूरी तरह से बेहतर नहीं बनाएगा। रोइ और वह सब ...
सारा

3

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

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

दूसरी ओर, मैं आपको समीक्षा के दौरान परीक्षण / कोड के साथ FIDDLE करने की सलाह देता हूं। कुछ तोड़ने की कोशिश करो। अगर एक शर्त है तो टिप्पणी करें। एक बूलियन को शाब्दिक सच / झूठ के साथ बदलें। देखें कि क्या परीक्षण विफल हो रहे हैं।

लेकिन हाँ, सभी में, मैं आपको अपने कोड के साथ एक साथ अपने परीक्षण लिखने की सलाह देता हूं और फिर एक ही बार में इसकी समीक्षा करता हूं।


2

यह निर्भर करता है कि आप कोड समीक्षा में क्या कर रहे हैं। मुझे लगता है कि उस स्तर पर परीक्षण लिखने के दो मुख्य कारण हैं:

  • सबसे पहले, यदि आप कोड की समीक्षा के दौरान भी रिफैक्टरिंग करते हैं, और आप ध्यान दें कि आप जिस तरह का रिफलैक्ट करना चाहते हैं, उसे कवर करने के लिए पर्याप्त यूनिट टेस्ट नहीं हैं, तो ऐसे टेस्ट जोड़ें

  • दूसरा, यदि कोड आपको ऐसा लगता है जैसे कि इसमें बग हो सकता है और आप चाहते हैं कि यह साबित हो (या इसे अस्वीकृत), इसके लिए एक परीक्षण लिखें

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

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


2

नहीं, यह मत करो। आपको लगता है कि उन्हें TDD भयानक है।

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

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

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

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


1

कोड की समीक्षा के दौरान इकाई परीक्षण विकास के दौरान इकाई परीक्षणों के लिए एक खराब विकल्प हैं।

आप जो सुझाव दे रहे हैं, वह बहुत ही सहज रूप से समझ में आता है। समीक्षा किस लिए? यह जाँचने के लिए कि कोड अच्छा है। परीक्षण क्या हैं? यह जाँचने के लिए कि कोड अच्छा है। तो क्यों नहीं दो गठबंधन?

यहाँ पर क्यों।

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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