टीडीडी में, परीक्षण के तहत सुविधा लागू करने वाले व्यक्ति द्वारा परीक्षण लिखे जाने चाहिए?

Question

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

Answer 1

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

मुझे लगता है कि स्वीकृति परीक्षण लिखने के लिए एक और व्यक्ति/टीम/या यहां तक ​​कि क्लाइंट (जब आप फिटनेस जैसे टूल का उपयोग करते हैं) होना संभव होगा, जो उच्च स्तर पर पूरी कार्यक्षमता का परीक्षण करेगा।

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

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

एटी दृढ़ता से अनुशंसा करता है कि टीडीडी को पहले लिखित परीक्षा की आवश्यकता है।

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

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

---

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

Answer 7

मैं यहां थोड़ा उलझन में हूं।

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

यदि आप कुछ अलग करना चाहते हैं, तो इसके लिए जाएं और ब्लॉग या आलेख में अपने अनुभव लिखें।

आपको यह नहीं कहना चाहिए कि आप जो कुछ भी करते हैं वह टीडीडी है।

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

कृपया The Three Rules Of Tdd देखें।

Answer 8

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

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