टीडीडी - अंदर से बाहर बनाम में

Question

टीडीडी का उपयोग करके इनसाइड आउट के निर्माण में आउटसाइड बनाम एक एप्लिकेशन के निर्माण के बीच क्या अंतर है ?

ये वे पुस्तकें हैं जो मैंने टीडीडी और यूनिट परीक्षण के बारे में पढ़ीं:
टेस्ट ड्रिवेन डेवलपमेंट: उदाहरण के लिए
टेस्ट-ड्रिवेन डेवलपमेंट: ए प्रैक्टिकल गाइड: ए प्रैक्टिकल गाइड
रियल-वर्ल्ड सॉल्यूशंस फॉर डेवलपिंग हाई-क्वालिटी पीएचपी फ्रेमवर्क एंड एप्लीकेशंस
टेस्ट-ड्रिवेन डेवलपमेंट इन माइक्रोसॉफ्ट। NET
xUnit टेस्ट पैटर्न: टेस्ट कोड कोड को बदलना
कला की इकाई परीक्षण: उदाहरणों में .Net
बढ़ते ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के साथ, टेस्ट द्वारा निर्देशित ---> यह वास्तव में समझना मुश्किल था क्योंकि जावा मेरी प्राथमिक भाषा नहीं है :)

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

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

हालाँकि, मैं xUnit टेस्ट पैटर्न में एक पैराग्राफ में आया था जिसमें लोगों ने TDD से संपर्क करने के तरीकों पर चर्चा की थी। वहाँ वहाँ बाहर 2 स्कूल हैं में बाहर बनाम इनसाइड आउट ।

अफसोस की बात है कि इस बिंदु पर पुस्तक अधिक विस्तृत नहीं है। मैं जानना चाहता हूं कि इन 2 मामलों में मुख्य अंतर क्या है।
मुझे उनमें से हर एक का उपयोग कब करना चाहिए?
एक TDD शुरुआत करने के लिए कौन सा आसान है?
प्रत्येक विधि की कमियां क्या है?
क्या इस विषय पर विशेष रूप से चर्चा करने वाली कोई सामग्री है?

Comments

XUnit टेस्ट पैटर्न साइट पर दो दृष्टिकोण वर्णित हैं: xunitpatterns.com/Philosophy%20Of%20Test%20Automation.html । यह अजीब है कि वे किताब में नहीं हैं।

— गुरिल्ला

Answer 1

इनसाइड-आउट और आउटसाइड काफी दुर्लभ शब्द हैं, अधिक बार मैंने क्लासिक स्कूल और लंदन स्कूल के बारे में सुना / पढ़ा है ।

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

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

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

आप जो भी उपयोग करते हैं, अधिक बार नहीं यह स्थितिजन्य है।

आगे पढ़ने के लिए, इस अंतर (कैसे हो सकता है) की उत्पत्ति के बारे में दिलचस्प चर्चा के साथ Google समूह पोस्ट है और लंदन सबसे उपयुक्त नाम क्यों नहीं हो सकता है।

Comments

दिलचस्प। आप इस निष्कर्ष पर कैसे पहुंचे कि टीडीडी में बाहर "मॉकडिस्ट" टीडीडी है? मैं बहुत सोच-समझकर और डिजाइन करना पसंद करता हूं और इस तरह टेस्टिंग (देखें softwareonastring.com/2015/01/10/… ) फिर भी फाउलर लेख मुझे फाउलर के साथ क्लासिकिस्ट कैंप में मजबूती से खड़ा करता है। Mockist हमेशा एक बाहर-इन दृष्टिकोण का उपयोग कर सकते हैं, आप इसे बिलकुल पलट गया और कहते हैं कि बाहर में डिजाइन और परीक्षण नहीं किया जा सकता है mockist TDD। आउट-इन और क्लासिकिस्ट टीडीडी-इर्स द्वारा बहुत अधिक अभ्यास किया जा सकता है।

— मार्जन वेनमा

@jimmy_keen - बाहर के साथ, क्या आप किसी भी बिंदु पर बाद में बनाए गए वास्तविक कार्यान्वयन के साथ उच्च स्तरीय परीक्षणों में मोक्स को बदलते हैं? या क्या आप उन्हें नकली निर्भरता के रूप में छोड़ देते हैं और फिर एकीकरण परीक्षण के रूप में पूरे उत्पादन कोड का उपयोग करते हैं?

— thehowler

मैं असहमत हूं कि क्लासिक / मॉकिस्ट और इनसाइड-आउट / आउटसाइड-इन संबंधित हैं। वे ऑर्थोगोनल हैं। आप अंदर-बाहर / बाहर का उपयोग कर सकते हैं।

— डैनियल कपलान

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

— गिलोय ३१

मुझे नहीं लगता कि यह बाहर की प्रक्रिया का सही वर्णन है। यह सार्वजनिक इंटरफेस से युग्मन के बिना इंटर्नल्स तक परीक्षण के बारे में है, जितना संभव हो।

— mcintyre321

Answer 2

संक्षिप्त उत्तर: हमेशा की तरह यह आपकी कोडिंग वरीयता और टीम के दृष्टिकोण पर निर्भर करेगा ।

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

• दूसरा स्तर तकनीकी है और इसका उपयोग आवेदक परतों के साथ करना है। मूल रूप से कोडिंग का मतलब मूल रूप से UI से शुरू होता है और अंदर की तरफ केंद्रीय परत (आमतौर पर व्यवसाय / डोमेन परत) पर जाता है। इसका मतलब अंदर-बाहर कोडिंग के विपरीत है जो केंद्रीय परत से शुरू होता है और बाहरी परतों को कोड करता है।

तो आप बाहर के साथ-साथ कोडिंग या अंदर-बाहर कोडिंग में डिज़ाइन कर सकते थे।

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

दूसरे शब्दों में, मॉकिस्ट या क्लासिकिस्ट शैली टीडीडी आईएमओ है जो कोडिंग के बाहर / अंदर / बाहर एक ऑर्थोगोनल चिंता है। आप पूरी तरह से अंदर बाहर दृष्टिकोण के साथ एक मॉकिस्ट शैली का उपयोग कर सकते हैं। इसके पीछे कारण यह है कि मॉकिस्ट / क्लासिकिस्ट शैली कोड निर्भरता के बारे में है जबकि बाहर-अंदर / अंदर-बाहर कोडिंग एप्लिकेशंस परतों के बारे में है ।

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

रॉबर्ट "अंकल बॉब" मार्टिन ने संक्षेप में अंदर-बाहर कोडिंग का उल्लेख किया है और यह आवश्यक नहीं है कि उनकी पोस्ट " क्लीन आर्किटेक्चर " में एक डिकॉउन्ड आर्किटेक्चर के साथ संघर्ष हो ।