कार्यप्रणाली: किसी अन्य डेवलपर के लिए लेखन इकाई परीक्षण

28

मैं सॉफ्टवेयर डेवलपमेंट और राइटिंग यूनिट टेस्ट के बारे में सोच रहा था। मुझे निम्नलिखित विचार आया:

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

मुझे लगता है कि इस विचार में कुछ बदलाव हैं:

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

शायद कोड और परीक्षणों के विकास के बीच कोड की समीक्षा के लिए किसी अन्य डेवलपर को जोड़ना भी अच्छा है।

इस विचार के नीचे क्या हैं? क्या यह पहले से ही कुछ अज्ञात-से-मुझे पद्धति के रूप में वर्णित है और सॉफ्टवेयर विकास में उपयोग किया जाता है?

पुनश्च। मैं एक पेशेवर परियोजना प्रबंधक नहीं हूं, लेकिन मैं परियोजना विकास प्रक्रियाओं के बारे में कुछ जानता हूं और कुछ सबसे लोकप्रिय तरीकों को जानता हूं - लेकिन यह विचार मेरे लिए परिचित नहीं है।

unit-testing methodology

— franiis
स्रोत

17

आप बस इकाई स्तर पर बहाव QA का वर्णन कर रहे हैं। यदि आपके पास कुछ काम करने वाले लोगों के जोड़े हैं, तो क्या आपने TDD के साथ वास्तविक जोड़ी प्रोग्रामिंग की कोशिश की है?

— जोंशरशेप

9

यह बेहतर होगा अगर परीक्षण लेखक पहले परीक्षण (कंकाल कोड लिखो) करेगा और दूसरे ने कार्यक्षमता को लागू किया। पहला डिजाइन के नियंत्रण में होगा और दूसरा भारी उठाने के लिए। अगर वह पहले से जानता है कि वह क्या कर रहा है तो अच्छी तरह से काम कर सकता है और दूसरा व्यक्ति हर समय अपने नेतृत्व का पालन नहीं करता है। मुझे सह-संचालन के इस तरीके के लिए एक नाम के बारे में नहीं पता है। मैं कहूँगा .. यह दावा! इस फ्रैंसिस विकास को कॉल करना शुरू करें।

— मार्टिन माट

14

उस आलोचना का कोई मतलब नहीं है, और आपका सुझाव उस समस्या को हल नहीं करता है।

— जोंशरशेप

5

@franiis मैंने देखा है कि सहकर्मी assert trueपरीक्षण के रूप में लिखते हैं और इसे एक दिन कहते हैं क्योंकि हर परीक्षा गुजर रही थी। एक महत्वपूर्ण कदम गायब था: परीक्षणों को पहले विफल होना चाहिए, और कोड को बदलकर पास करना चाहिए, न कि परीक्षण।

— एरिक डुमिनील

6

@franiis TDD को पुनरावृति के चारों ओर बनाया गया है। असफल परीक्षण लिखें। कोड लिखें जो परीक्षण को हरा बनाता है। Refactor। एक असफल परीक्षा लिखें। कोड लिखें जो परीक्षण को हरा बनाता है। Refactor। ऐसा लगता है कि आप उस भाग को याद कर रहे हैं "जब तक आपके पास परीक्षण न हों जो आपकी सभी आवश्यकताओं को कवर करते हैं"। लेकिन आपको जो सबसे बड़ी समस्या दिखती है वह यह है कि "परीक्षण" को कुछ ऐसी चीज़ों के रूप में देखा जाता है जो आपके पास होनी चाहिए क्योंकि किसी ने ऐसा कहा, बजाय परीक्षणों के डेवलपर्स के लिए एक उपयोगी उपकरण होने के नाते । यदि आप लोगों को उनके कोड की गुणवत्ता (और शुद्धता) की परवाह नहीं कर सकते हैं, तो यह आपकी समस्या है, और यहीं से आपको शुरुआत करनी चाहिए।

— लुआं

30

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

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

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

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

— थॉमस ओवेन्स
स्रोत

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

— फ्रांसिस

मेरे अनुभव में, इस दृष्टिकोण के लाभों को फिर से शुरू करने में लागत लगती है। मैं 'पिंग-पोंग' या किसी अन्य विधि का उपयोग करके इन कर्तव्यों से दूर व्यापार करना चाहता हूं।

— नॉनटेपिर

3

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

— लॉरेंट ला रिज़्ज़ा

@LaurentLARIZZA जो सही लगता है। मुझे लगता है कि यह कहने का एक बेहतर तरीका होगा कि "जोड़ी प्रोग्रामिंग का अभ्यास अब गति के बारे में नहीं है, लेकिन भविष्य में गुणवत्ता और गति है।" यह निश्चित रूप से पहले की समस्याओं को खोजने, काम की मजबूती में सुधार करने और साइलो को फाड़ने के लिए ज्ञान को साझा करने के लिए एक अग्रगामी अभ्यास है। इन सभी में अब एक लागत है जो अक्सर भविष्य में पुरस्कार का भुगतान करेगी।

— थॉमस ओवेन्स

@ThomasOwens: ठीक है, गुणवत्ता की लागत केवल माना जाता है, वास्तविक नहीं। एक बार जब आपका परीक्षण पास हो जाता है (और आपने अपना कोड टिड्ड कर दिया है), तो आपके परीक्षण द्वारा वर्णित परिदृश्य किया जाता है और सुरक्षित हो जाता है, और आपको विश्वास हो जाता है कि यह अपेक्षित है। यह हो चुका है, और आप आगे बढ़ सकते हैं। यदि आप इस निश्चितता के बिना आगे बढ़ते हैं कि कोड काम करता है, तो आपने सिर्फ एक ऋण स्वीकार किया है जिसे बाद में चेक को निष्पादित करना होगा। ऋण की लागत, ऋण की अनुपस्थिति। मेरा मतलब है, आप जिस "भविष्य" के बारे में बात करते हैं, जैसे ही आपका पहला टेस्ट पास होता है।

— लॉरेंट ला रिज़्ज़ा

37

आपके विचार में मुख्य समस्या यह है कि आप किसी भी कोड के लिए परीक्षण नहीं लिख सकते। कोड को परीक्षण योग्य होना चाहिए।

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

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

— ईवान
स्रोत

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

— फ्रांसिस

1

@franiis यकीन है, मुख्य समस्या यह नहीं है कि आप परीक्षणों को लिखने के बाद, ऐसा करने के संयोजन और एक ही व्यक्ति नहीं होने के कारण जो कोड लिखा था।

— इवान

लेकिन अगर उदाहरण के लिए जोड़े की प्रोग्रामिंग का उपयोग करना कम समय लेने वाला होगा। यदि दो डेवलपर्स एक टर्मिनल पर काम करते हैं, तो वे किसी भी तरह से समवर्ती रूप से दो सुविधाओं पर काम नहीं कर सकते हैं, और मेरे विचार से इसे (सीमित दायरे में भी) की अनुमति दी जानी चाहिए। 2-व्यक्ति माइक्रो-टीम के लिए मीटिंग वास्तविक बोझ नहीं होनी चाहिए।

— फ्रांसिस

25

@franiis: "यदि परीक्षण कोड के कुछ पहलू का परीक्षण नहीं करते हैं, तो इसे कोड में छोड़ा जा सकता है।" - पूरी बात यह है। परीक्षण निष्पादन योग्य उदाहरण के रूप में आवश्यकताओं का एन्कोडिंग हैं। यदि इसके लिए कोई परीक्षण नहीं है, तो इसके लिए कोई आवश्यकता नहीं है, और इसके लिए कोई कोड नहीं होना चाहिए ।

— जोर्ग डब्ल्यू मित्तग

3

@ JörgWMittag ने जो कहा उसका दूसरा पक्ष होगा: यदि आपके परीक्षण "कोड के कुछ महत्वपूर्ण परीक्षण नहीं करते हैं", तो आपको अपने परीक्षणों को ठीक करने की आवश्यकता है। यह आपके सिस्टम में उतना ही सही होगा जितना कि पारंपरिक TDD में।

— बटा

15

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

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

तो हाँ, एक दूसरा देव लिखने के लिए अतिरिक्त इकाई परीक्षण का अर्थ है, लेकिन विशेष रूप से इकाई परीक्षण लिखने के लिए नहीं ।

— डॉक्टर ब्राउन
स्रोत

7

निम्नलिखित स्थितियों में से किसी के होने की संभावना प्रतीत होती है - ये सभी अवांछनीय हैं:

उलझन

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

विवाद

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

प्रसंग स्विचिंग

यहां तक कि अगर डेवलपर बी डेवलपर ए द्वारा लिखे गए कोड का परीक्षण करने के लिए अपने विकास को आश्रय देने के लिए तैयार है - गतिविधि में परिवर्तन एक लागत पर आता है।

यह दशकों से स्वीकार किया गया है कि मैन पावर को दोगुना करने से विकास का समय कम नहीं होता है। जिन कारकों को मैंने ऊपर उल्लिखित किया है, उन्हें देखते हुए, यह देखना मुश्किल है कि यह व्यवस्था कैसे चीजों को बेहतर करेगी।

— रोबी डी
स्रोत

4

जब जोड़ी प्रोग्रामिंग और TDD के साथ संयोजन में उपयोग किया जाता है तो इसे पिंग पोंग पैटर्न कहा जाता है :

A एक नया परीक्षण लिखता है और देखता है कि यह विफल हो गया है।

बी परीक्षा पास करने के लिए आवश्यक कोड को लागू करता है।

B अगला परीक्षण लिखता है और देखता है कि यह विफल है।

परीक्षण को पास करने के लिए आवश्यक कोड को लागू करता है।

और इसी तरह। जब भी ड्राइविंग की जरूरत होती है, तो रिफैक्टरिंग की जाती है।

लेकिन आपको लगता है कि दोनों प्रोग्रामर कोड अलग-अलग कंप्यूटरों के साथ प्रस्तावित करते हैं। इसे अलग-अलग करने से बहुत निम्न स्तर के विनिर्देशन की आवश्यकता होगी। यह फुर्तीली मेटोडोलॉजी के खिलाफ जाता है। हर परिवर्तन को समन्वित करने की आवश्यकता होगी। टीडीडी में आप मक्खी पर निम्न स्तर के desing कर रहे हैं और यह कोई समस्या नहीं है। मुझे लगता है कि आपके aproach को पहले से ही कोडेड कंकालों के कुछ प्रकार की आवश्यकता होगी।

वैसे भी: आप 100% कुशल नहीं हैं, भले ही चीजों को करने के नए तरीकों का परीक्षण करके बहुत कुछ सीख सकते हैं। आप इसका परीक्षण कर सकते हैं और अपने वास्तविक जीवन के अनुभव को साझा कर सकते हैं

— Borjab
स्रोत

3

मैं इस पार्टी में देरी से आ रहा हूं, लेकिन मुझे लगता है कि मुझे कुछ जोड़ना है।

क्या यह पहले से ही कुछ अज्ञात-से-मुझे पद्धति के रूप में वर्णित है और सॉफ्टवेयर विकास में उपयोग किया जाता है?

आप पीयर टेस्टिंग का वर्णन कर रहे हैं ।

चलो मान लेते हैं कि हमारे पास डेवलपर्स के जोड़े हैं।

आह, अच्छा ओएल ' जोड़ी प्रोग्रामिंग ।

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

वह पेयर प्रोग्रामिंग नहीं है।

आदर्श रूप से वे दो समान आकार की विशेषताओं पर काम करेंगे और फिर परीक्षण की तैयारी के लिए विनिमय करेंगे।

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

इसका दूसरा नाम व्हाइटबॉक्स टेस्टिंग है । हालाँकि यह परिभाषा खुद को इस बात से चिंतित नहीं करती है कि परीक्षण कौन कर रहा है, इस तथ्य के साथ कि परीक्षक को उस चीज़ के आंतरिक कामकाज को देखने को मिलता है जो वे परीक्षण कर रहे हैं, ब्लैक बॉक्स परीक्षण के विपरीत, जहां वे केवल देखते हैं कि क्या अंदर जाता है; क्या निकलता है। ब्लैक बॉक्स आमतौर पर QA क्या करता है।

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

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

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

— candied_orange
स्रोत

प्रतिक्रिया और मुझे सहकर्मी परीक्षण की ओर इशारा करने के लिए धन्यवाद (मैं इसके बारे में पढ़ूंगा)।

— फ्रांसिस

1

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

परीक्षण किसी के द्वारा लिखे गए हैं, जो कार्यान्वयन के बारे में अधिक देख सकते हैं

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

जोड़ी प्रोग्रामिंग की तुलना में काम थोड़ा तेज किया जाना चाहिए (एक ही समय में दो विशेषताएं)

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

दोनों परीक्षणों और कोड के पास इसके लिए जिम्मेदार व्यक्ति है

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

कोड का परीक्षण कम से कम दो लोगों द्वारा किया जाता है

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

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

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

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

— l0b0
स्रोत

यह तेजी से (संभवतया) होगा क्योंकि आपके पास दो लोग "समान काम" नहीं कर रहे हैं - वे प्रत्येक अपनी चीज कर रहे हैं और फिर आंशिक रूप से स्वैप कर रहे हैं।

— जैकब रायल

@JacobRaihle जोड़ी बिना संचार के साथ-साथ विकसित होने वाले दो लोग नहीं हैं। वही काम करने वाले दो लोग होंगे। जोड़ी बनाना वास्तव में कुशल है क्योंकि दो लोग एक काम में सहयोग कर रहे हैं । मेरे अनुभव में विकास व्यक्तिगत प्रोग्रामर (यानी, जोड़े को दो बार तेजी से काम करने के लिए) के रूप में उपवास के बारे में है, जिसके परिणामस्वरूप सॉफ्टवेयर बहुत अधिक गुणवत्ता वाला है और ज्ञान साझा किया गया है।

— l0b0

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

— जैकब रायल

1

मुझे लगता है कि इस विचार में कुछ बदलाव हैं:

लेट्स एक-एक करके उनके माध्यम से चलते हैं।

परीक्षण किसी के द्वारा लिखे गए हैं, जो कार्यान्वयन के बारे में अधिक देख सकते हैं,

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

जोड़ी प्रोग्रामिंग की तुलना में काम थोड़ा तेज किया जाना चाहिए (एक ही समय में दो विशेषताएं)

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

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

परीक्षण और कोड दोनों के लिए जिम्मेदार व्यक्ति है,

XP द्वारा प्रस्तावित सामूहिक कोड स्वामित्व में देखें। आपके पास कोड के लिए और भी अधिक लोग होंगे। यदि आपका लक्ष्य डेवलपर्स के बीच ज्ञान साझा करना है, तो आप उन्हें अलग क्यों करना चाह रहे हैं?

कोड का परीक्षण कम से कम दो लोगों द्वारा किया जाता है

जोड़ी के साथ TDD भी। जोड़ी बनाते समय, दोनों लोगों को इस बात पर सहमत होना होगा कि लिखित कोड पर्याप्त है या नहीं। अगर इससे लड़ाई होती है, तो टीम के कुछ लोगों को गलत अहंकार की समस्या होती है।

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

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

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

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

— लॉरेंट ला रिज़ज़ा
स्रोत