टेस्ट-ड्रिवेन डेवलपमेंट एक टेस्ट-फर्स्ट सॉफ्टवेयर डेवलपमेंट मेथडोलॉजी है, जिसका मतलब है कि वास्तविक कोड लिखने से पहले टेस्ट कोड लिखने की आवश्यकता होती है। केंट बेक के शब्दों में:
यहाँ शैली कोड की कुछ पंक्तियों को लिखने के लिए है, फिर एक परीक्षण जिसे चलाने के लिए, या उससे भी बेहतर होना चाहिए, एक परीक्षण लिखने के लिए जो नहीं चलेगा, फिर उस कोड को लिखें जो इसे चलाएगा।
यह पता लगाने के बाद कि कोड का एक छोटा टुकड़ा कैसे लिखा जाए, अब, केवल कोडिंग के बजाय, हम तत्काल प्रतिक्रिया प्राप्त करना चाहते हैं और अभ्यास "कोड थोड़ा, परीक्षण थोड़ा, कोड थोड़ा, परीक्षण थोड़ा।" इसलिए हम तुरंत इसके लिए एक परीक्षण लिखते हैं।
तो TDD एक निम्न-स्तरीय, तकनीकी कार्यप्रणाली है जो प्रोग्रामर स्वच्छ कोड का उत्पादन करने के लिए उपयोग करते हैं जो काम करता है।
व्यवहार-प्रेरित विकास एक पद्धति है जिसे टीडीडी पर आधारित बनाया गया था, लेकिन यह एक ऐसी प्रक्रिया में विकसित हुआ, जो केवल प्रोग्रामर और परीक्षक की चिंता नहीं करता, बल्कि पूरी टीम और सभी महत्वपूर्ण हितधारकों, तकनीकी और गैर-तकनीकी से संबंधित है। BDD ने कुछ सरल प्रश्नों से शुरुआत की, जिनका TDD अच्छी तरह से उत्तर नहीं देता है: मुझे कितने परीक्षण लिखने चाहिए? मुझे वास्तव में क्या परीक्षण करना चाहिए - और मुझे क्या नहीं करना चाहिए? मेरे द्वारा लिखे गए परीक्षणों में से कौन सा वास्तव में व्यवसाय के लिए या उत्पाद की समग्र गुणवत्ता के लिए महत्वपूर्ण होगा, और जो सिर्फ मेरी ओवर-इंजीनियरिंग हैं?
जैसा कि आप देख सकते हैं, ऐसे सवालों के लिए प्रौद्योगिकी और व्यवसाय के बीच सहयोग की आवश्यकता होती है। व्यावसायिक हितधारक और डोमेन विशेषज्ञ अक्सर इंजीनियरों को बता सकते हैं कि किस तरह के परीक्षण ध्वनि की तरह होते हैं जैसे कि वे उपयोगी होंगे - लेकिन केवल यदि परीक्षण उच्च-स्तरीय परीक्षण हैं जो महत्वपूर्ण व्यावसायिक पहलुओं से निपटते हैं। BDD ऐसे व्यवसाय-जैसे परीक्षणों को "उदाहरण" कहता है, जैसे कि "मुझे यह बताएं कि यह सुविधा कैसे सही ढंग से व्यवहार करनी चाहिए," का एक उदाहरण है, और निम्न-स्तरीय, डेटा सत्यापन या परीक्षण API एकीकरण जैसी तकनीकी जाँच के लिए शब्द "परीक्षण" को सुरक्षित रखता है। महत्वपूर्ण हिस्सा यह है कि जबकि परीक्षण केवल प्रोग्रामर और परीक्षकों द्वारा बनाए जा सकते हैं, उदाहरणों को पूरी डिलीवरी टीम द्वारा - डिजाइनरों, विश्लेषकों, और इसी तरह से एकत्र और विश्लेषण किया जा सकता है।
एक वाक्य में, BDD मैं का सबसे अच्छा परिभाषाओं में से एक है पाया अब तक BDD के बारे में है कि "डोमेन के विशेषज्ञों के साथ बातचीत करने के और उदाहरण का उपयोग करते हुए वांछित व्यवहार का एक साझा समझ पाने और अज्ञात की खोज के लिए।" खोज हिस्सा बहुत महत्वपूर्ण है। जैसा कि डिलीवरी टीम अधिक उदाहरण एकत्र करती है, वे व्यवसाय के डोमेन को अधिक से अधिक समझना शुरू करते हैं और इस प्रकार वे उस उत्पाद के कुछ पहलुओं के बारे में अपनी अनिश्चितता को कम करते हैं जिनसे उन्हें निपटना पड़ता है। जैसे ही अनिश्चितता घटती है, रचनात्मकता और वितरण टीम की स्वायत्तता बढ़ती है। उदाहरण के लिए, वे अब अपने स्वयं के उदाहरणों का सुझाव देना शुरू कर सकते हैं जो कि व्यावसायिक उपयोगकर्ताओं को नहीं लगता था कि उनकी तकनीकी विशेषज्ञता की कमी के कारण संभव नहीं था।
अब, व्यापार और डोमेन विशेषज्ञों के साथ बातचीत करने में बहुत अच्छा लगता है, लेकिन हम सभी जानते हैं कि यह अक्सर अभ्यास में कैसे समाप्त होता है। मैंने एक प्रोग्रामर के रूप में टेक के साथ अपनी यात्रा शुरू की। प्रोग्रामर के रूप में, हमें कोड- एल्गोरिदम, डिज़ाइन पैटर्न, अमूर्त लिखना सिखाया जाता है । या, यदि आप एक डिजाइनर हैं, तो आपको डिजाइन करना सिखाया जाता है- जानकारी को व्यवस्थित करें और सुंदर इंटरफेस बनाएं। लेकिन जब हम अपनी एंट्री-लेवल जॉब प्राप्त करते हैं, तो हमारे नियोक्ता हमसे उम्मीद करते हैं कि "ग्राहकों को मूल्य प्रदान करें।" और उन ग्राहकों में से हो सकता है, उदाहरण के लिए ... एक बैंक। लेकिन मुझे बैंकिंग के बारे में कुछ भी नहीं पता था — सिवाय इसके कि कैसे अपने खाते के बैलेंस को कुशलता से घटाया जाए। इसलिए मुझे किसी भी तरह से अनुवाद करना होगा जो मुझसे कोड में अपेक्षित है ... यदि मुझे कोई मूल्य वितरित करना है तो मुझे बैंकिंग और मेरी तकनीकी विशेषज्ञता के बीच एक पुल का निर्माण करना होगा। BDD मुझे डिलीवरी टीम और डोमेन विशेषज्ञों के बीच द्रव संचार की एक स्थिर नींव पर इस तरह के पुल का निर्माण करने में मदद करता है।
और अधिक जानें
यदि आप BDD के बारे में अधिक पढ़ना चाहते हैं, तो मैंने इस विषय पर एक पुस्तक लिखी। "राइटिंग ग्रेट स्पेसिफिकेशंस" आवश्यकताओं का विश्लेषण करने की कला की खोज करता है और आपको यह सीखने में मदद करेगा कि एक महान बीडीडी प्रक्रिया का निर्माण कैसे करें और उस प्रक्रिया के मुख्य भाग के रूप में उदाहरणों का उपयोग करें। पुस्तक सर्वव्यापी भाषा के बारे में बात करती है, उदाहरणों को इकट्ठा करती है, और तथाकथित निष्पादन योग्य विनिर्देशों (स्वचालित परीक्षणों) को उदाहरणों से बाहर कर देती है - तकनीक जो बीडीडी टीमों को समय पर और बजट पर बहुत सॉफ्टवेअर देने में मदद करती है।
अगर आप "राइटिंग ग्रेट स्पेसिफिकेशन्स" खरीदने में रुचि रखते हैं, तो आप प्रोमो कोड 39nicieja2 के साथ 39% बचा सकते हैं :)