क्या टेस्ट संचालित विकास डिजाइन से फोकस लेता है?

Question

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

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

मुझे परीक्षण के साथ संचालित करने में कोई समस्या नहीं है। कोई विचार?

Answer 1

यह हमेशा एक संतुलन है:
- बहुत अधिक टीडीडी और आप काम करने वाले कोड के साथ समाप्त होते हैं, लेकिन काम करने के लिए दर्द होता है।
- बहुत ज्यादा 'maintable कोड, स्वच्छ डिजाइन, और ध्वनि वास्तुकला' और आप Architecture Astronauts कि खुद सब बातों में पक्षाघात कोडिंग

मॉडरेशन में बात की है के साथ खत्म।

Answer 2

सं

अगर सही किया, टेस्ट प्रेरित विकास अपने डिजाइन उपकरण है।

मुझे आशा है कि आप मुझे my own blog entry, wherein I discuss the pitfalls of Test Driven Development that went wrong से जोड़ने के लिए क्षमा करें क्योंकि डेवलपर्स ने केवल परीक्षणों के रूप में अपने परीक्षणों का इलाज किया था।

TDD एक कार्य के रूप में इलाज किया गया था, जब यह :

पिछले एक परियोजना में, devs एक अत्यधिक हानिकारक सिंगलटन पैटर्न है कि परियोजना, जो सिर्फ पूरी बात को तोड़ दिया भर निर्भरता से लागू जब आवश्यकताओं बदल रहे थे इस्तेमाल किया को दृष्टिकोण के रूप में माना जाना चाहिए था। [...]

को पहचानने में विफलता थी कि टीडीडी परीक्षण के बारे में नहीं है, यह डिज़ाइन के बारे में है। यूनिट परीक्षणों में सिंगलटन दुरुपयोग के प्रचलित मामले ने बनाया यह स्पष्ट: परीक्षण लेखकों के बजाय "डब्ल्यूटीएफ ये सिंगलटन = मान है; मेरे परीक्षणों में कर रहे बयान? ", परीक्षण लेखकों ने बस को सिंगलटन को परीक्षणों में प्रचारित किया। 330 बार

दुर्भाग्यपूर्ण परिणाम यह है कि बिल्ड सर्वर-लागू परीक्षण पास किया गया था, जो कुछ भी हुआ था।

टेस्ट प्रेरित विकास, सही किया, डेवलपर्स अत्यधिक तंग युग्मन की तरह डिजाइन नुकसान के बारे में पता करना चाहिए, सूखी (अपने आप को दोहराने नहीं है) के उल्लंघन, SRP (एकल जिम्मेदारी सिद्धांत), आदि

के उल्लंघन

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

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

1. यह काम
2. यह सही
3. यह तेजी से

टेस्ट आप # 1 प्राप्त करें बनाएं:

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

TDD शो के

हाल के अध्ययनों से (Siniaalto और Abrahamsson) है कि यह पारंपरिक परीक्षण पिछले के विकास पर और कहा कि कोई लाभ हो सकता है:

Jim Coplien अब थोड़ी देर के लिए बिल्कुल इस विषय पर वार्ता दी है कुछ मामलों में कोड और बिगड़ गया है कि इसमें अन्य खतरनाक (उनके शब्द) प्रभाव हैं। जो मुझे चिंतित करता है सबसे अधिक यह है कि यह आर्किटेक्चर को खराब करता है। - Jim's blog

वहाँ भी रॉबर्ट सी मार्टिन और जेम्स Coplien जहां वे इस विषय पर स्पर्श जो discussion over on InfoQ है।

Answer 8

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

A great "debate" about this has been recorded रॉबर्ट सी मार्टिन और जेम्स कोप्लिएन के बीच, जहां पूर्व एक टीडीडी वकील है और बाद वाले ने कहा है कि यह एक प्रणाली के डिजाइन को खंडित करता है। , हम सभी की जरूरत है

"एक लग रहा है के बारे में '99 कि वास्तुकला अप्रासंगिक है के बाद से चंचल समुदाय में हुई है, हम वास्तुकला करने की ज़रूरत नहीं है: यह वही है रॉबर्ट TDD और डिजाइन के बारे में कहा है ऐसा करने के लिए परीक्षण की एक बहुत लिखने और कहानियों में से बहुत करते हैं और कर त्वरित पुनरावृत्तियों और कोड ही जादुई इकट्ठा करेंगे, और यह हमेशा गया घोड़ा बकवास। मैं भी के सबसे लगता है मूल चंचल समर्थकों हैं सहमत हैं कि एक सभ्यता थी।"

जेम्स Coplien कहा गया है कि केवल TDD से अपने डिजाइन ड्राइविंग एक महान जोखिम है:

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

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

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

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

यहां दिलचस्प बात यह है कि दोनों TDD प्रस्तावक और TDD प्रतिपक्षी कह रहे हैं कि आप सामने डिजाइन की जरूरत है।

यदि आपके पास समय है, तो वीडियो देखें। यह दो अत्यधिक प्रभावशाली विशेषज्ञों के बीच एक महान चर्चा है, और यह केवल 22 मिनट लंबा है।

Answer 9

इसके बारे में सोचने का मेरा तरीका यह है कि आप अपना कोड पहले जैसा दिखाना चाहते हैं। एक बार जब आपके पास अपने लक्ष्य कोड का नमूना हो (जो अभी कुछ भी नहीं करता है) देखें कि क्या आप उस पर एक परीक्षण मचान डाल सकते हैं। यदि आप ऐसा नहीं कर सकते हैं, तो पता लगाएं कि आप क्यों नहीं कर सकते हैं। समय है क्योंकि आप एक गरीब डिजाइन निर्णय (99%) बनाया यह है, लेकिन यदि यह मामला नहीं है के अधिकांश (1%) की कोशिश निम्नलिखित:

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

आपके पास अपना लक्षित कोड और परीक्षण मचान होने के बाद। कोड लागू करें। अब आपको यह जानने का लाभ भी है कि आप अपनी प्रगति को कितनी अच्छी तरह से पार करते हैं (यह एक महान प्रेरक है!)

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

Answer 10

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

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

व्यापक अनुभवजन्य डेटा सिद्धांत को साबित करता है। सिएनियाल्टो और अब्राहमसन, (कार्यक्रम डिजाइन और टेस्ट कवरेज पर टेस्ट-संचालित विकास के प्रभाव पर तुलनात्मक केस स्टडी), ईएसईएम 2007, ने पाया कि "हमारे नतीजे बताते हैं कि समेकन खराब हो सकता है (भले ही बेक का दावा है कि टीडीडी अत्यधिक उत्पादन करता है एकजुट प्रणाली)। हमारे दूसरे अध्ययन में हमने देखा कि जटिलता उपायों टीडीडी के साथ बेहतर थे, लेकिन निर्भरता प्रबंधन मीट्रिक स्पष्ट रूप से बदतर थे। " Janzen और Saledian (क्या टेस्ट-संचालित विकास वास्तव में सॉफ्टवेयर डिजाइन गुणवत्ता में सुधार करता है? आईईईई सॉफ्टवेयर 25 (2), मार्च/अप्रैल 2008, पीपी 77 - 84) ने पाया कि "[टी] के परिणामस्वरूप उन्होंने निचले स्तर के दावों का समर्थन नहीं किया युग्मन और टीडीडी के साथ एकजुटता बढ़ी "।

एक साहित्य समीक्षा इन मामलों को आगे बढ़ाने वाले अन्य प्रकाशनों को उजागर करेगी।

यहां तक ​​कि मेरे प्यारे दोस्त अंकल बॉब लिखते हैं: "चुस्त विकास की अधिक कपटपूर्ण और लगातार मिथकों में से एक यह है कि सामने की वास्तुकला और डिजाइन खराब हैं, कि आपको कभी भी वास्तुशिल्प निर्णयों के सामने समय बिताना नहीं चाहिए।इसके बजाय आपको अपने वास्तुकला और डिजाइन को कुछ भी नहीं, एक समय में एक टेस्ट केस विकसित करना चाहिए। मुझे माफ करना, लेकिन यह है कि घोड़े छी है। "(" फुर्तीली वास्तुकला का scatology, " http://blog.objectmentor.com/articles/2009/04/25/the-scatology-of-agile-architecture)

हालांकि, यह ध्यान देने योग्य व्यापक विफलता है कि लोगों को लगता है कि यह एक डिजाइन तकनीक एक परीक्षण तकनीक के बजाय है लायक है। ओशरोव कई दृष्टिकोणों को इंगित करता है जिन्हें अक्सर टीडीडी के साथ समान रूप से समझा जाता है। मुझे यह सुनिश्चित नहीं हो सकता है कि पोस्टर द्वारा क्या मतलब है। देखें: http://weblogs.asp.net/rosherove/archive/2007/10/08/the-various-meanings-of-tdd.aspx